RFC (round 1), JEP draft: Low-level Object layout introspection methods

[Alan Bateman]

On 05/08/2020 11:35, Aleksey Shipilev wrote:
> Hi,
>
> I would like to solicit early feedback on "Low-level Object layout introspection methods" JEP:
>    https://openjdk.java.net/jeps/8249196
>
> It crosscuts core libraries and Hotspot, and therefore jdk-dev@ seems to be the mailing list to use
> for it.
>
> The work seems to be at the point where we understand the initial design and implementation
> constraints. Those are both reflected in JEP text (where possible), and in the prototype
> implementation (webrevs and builds are linked in JEP itself).
>
> The API itself is not cast in stone, and open for discussion. JEP text hopefully makes a good
> argument for each of new methods. Strong (dis)agreements about the existence of particular methods
> are good to have during this review, so we could swing the JEP direction early.
>
I think the consequences of exposing layout and address information in 
the standard API needs discussion. Although the intention seems to be 
for benign introspection by tools, and maybe a small number of super 
advanced libraries, I could imagine addressOf and fieldOffsetOf being 
misused. I don't have a good sense on how layout will be change in 
Project Valhalla with specialized generics to know if these APIs even 
make sense (I see you have a section already on the challenges with 
inline types).

As you note in the JEP, the Instrumentation and JVM TI APIs are for tool 
agents, not libraries. The getObjectSIze method was meant for profilers 
and other tooling that wanted to estimate memory usage. Those APIs have 
not been updated since Java 5 and probably need to be modernized so that 
might be useful to separate out for its own investigation. You list 
"heap dumps" as a non-alternative. The reason that the built-in heap 
dump generates VM-independent HPROF format is because that was the only 
format that tooling could consume at the time (Java 6). That is 
something that could be separated out too as it might be an interesting 
project to re-visit this area, maybe even augment the heap dump with 
something that would help heap dump analyzer get a better sense of the 
memory usage.

I see in the alternatives that you don't want to pursue moving JOL in 
the JDK. I think you could expand a bit more on this as I don't think 
"backports" or "support previous JDKs" are relevant, meaning I don't 
think it would need to be constrained by needing to work across 
different JDK builds/versions. Maybe this alternative is about more 
diagnostic options to print layout information, maybe it doesn't need a 
separate tool.

I'm sure you will get lots of other feedback on the draft JEP. My main 
concern is implications of putting these low-level APIs into the java.* 
API, whether it creates attractive nuisance, and/or will they be regrets 
in the long term as layouts get more sophisticated.

-Alan.