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

[Alan Bateman]

On 11/08/2020 11:22, Aleksey Shipilev wrote:
> :
> 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 should have been clearer. I didn't suggest JOL in its current form. 
Instead I think it is reasonable to ask if it would be useful for the 
JDK to include a JOL-like tool. No exported API beyond benign methods to 
provide estimate of size. It would be kept in sync with HotSpot so as 
layouts change or variant layouts are introduced. It would at least be 
useful when working on the JDK. That seems a lot more maintainable (to 
me anyway) than trying to keep a tool outside of the JDK in sync with 
interesting or unknown layout changes in the future. It's a bit like SA 
in that regard.

-Alan