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

[Aleksey Shipilev]

Hi Alan,

Thanks for taking a look!

On 8/5/20 2:03 PM, Alan Bateman wrote:
> On 05/08/2020 11:35, Aleksey Shipilev wrote:
> 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.

Yes, maybe. I don't want to creep the scope of this work, though.

> 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 don't quite see how moving JOL to JDK helps. I added that alternative after your initial review,
so please help me out here?

If we move the JOL in its current form, then all the new APIs would be accessible through JOL. In
other words, it would be the same API with extra steps. Which means all arguments about exposing
offsets, addresses and apply there as well. If we are talking about moving JOL and then disabling
some of its features (e.g. getting offsets and addresses), this is not _really_ moving JOL, but
rather a shallow version of it.

My argument about backports and supporting previous JDK still stands, and here is why. Currently,
JOL supports JDK 6..15. Every little bug that is found in JOL is automatically "released" for every
supported JDK version. If JOL is inside JDK, that means those bugfixes would need to be backported
to previous JDK releases. Basically, that asks JOL maintainers (well, me) to maintain several forked
versions of JOL. You can counter that with saying that only the latest version matters, but this is
where we would disagree philosophically.

> 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.

Quite. I believe JEP calls that out in Risks and Assumptions? I think the weasel-wording the
specification text is necessary to prevent _the informational APIs_ from blocking future VM work. I
was trying to capture that in many places in the text. Is that still not transparent?

More answers in reply to Brian...

-- 
Thanks,
-Aleksey