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

[Roman Kennke]

On Mon, 2020-08-17 at 14:33 +0200, Aleksey Shipilev wrote:
> 	Error verifying signature: Cannot verify message signature:
> Incorrect message format
> On 8/16/20 12:41 PM, Peter Levart wrote:
> > On 8/11/20 12:22 PM, Aleksey Shipilev wrote:
> > > ...but dislike:
> > >      public static long addressOf(Object obj);
> > >      public static long fieldOffsetOf(Field field);
> > 
> > What exactly is the purpose of "addressOf" method in terms of 
> > information API? Is it used to estimate relative placement of
> > several 
> > objects in the heap to see how they are scattered around which
> > affects 
> > the CPU cache performance when accessing them?
> 
> Yes, it says so in "Motivation" section in JEP. Additionally,
> checking the object address against
> the cache line size.
> 
> > If this is the case, then maybe the method could return a
> > "mangled" 
> > address: the address + some secret random value calculated once for
> > the 
> > whole VM.
> 
> Now that is an interesting suggestion!
> 
> Implemented here:
>   https://hg.openjdk.java.net/jdk/sandbox/rev/248807bfa78e
> 
> There is little-to-none loss of performance, because the offset can
> be trivially used in intrinsics.
> JEP text is updated to mention this technique. I believe this makes
> the address exposure story less
> problematic, although the result is still conceptually a useful proxy
> for a memory location.
> 

Maybe I'm missing something, but it may not actually have to be 'some
secret offset' but could be just the location of the object relative to
heap start?

Roman