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

[Roman Kennke]

> > Setting aside philosophy and stewardship for a moment, I think
> > what's really going on is that this
> > JEP is trying to serve two different audiences: those that are
> > happy to have estimates and/or use
> > the information for making approximate decisions, and those who are
> > interested in low-level hackery
> > for accessing the Java heap, rather than through `getfield` and
> > `putfield`.  I think if you were to
> > split this into two JEPs, you would find enthusiastic support for
> > the first, and strong resistance
> > to the second. 
> 
> With my JEP author hat on: JEP caters for low-level introspection use
> case, such as JOL and JAMM. It
> does not intend to cater for "low-level hackery for accessing the
> Java heap", and it tries to
> specifically make the argument that new APIs do not allow this low-
> level hackery beyond what is
> possible today and in a foreseeable future.
> 
> I can see that the JEP can be split in "non-controversial" (sizeOf,
> deepSizeOf) and "controversial"
> (addressOf, fieldOffsetOf) parts. For the process overhead reasons,
> I'd push forward with just one
> JEP at the moment, though.

I don't actually see much of a problem with addressOf() and
fieldOffsetOf() introspection. I can see that it *is* a problem with
current Unsafe, that also provides accessors to access and modify
object using this information, but such API is not included in this
JEP. And without any such method, how "useful" can it be for actual
hackery? Ok yes, we *could* perhaps pass this to native code and access
the address there, but even that would not reliably work, especially
not in the face of concurrently-evacuating GCs which can change the
object address at any time. As such, what is returned there are only
numbers that the caller needs to interpret in some way as a sort of
diagnostic value, but must be prepared for the values to change from
one call to the next, or even get the anser 'don't know'.

(As as side, there are some mistakes in the JEP text there: "... ways
to use this value in by feeding it ..." the "in" there seems too much.
"there are guarantees it would not poke around": there are *no*
guarantees.)

Roman