Design question: why not reuse the CMS slots in mark word?

[Roman Kennke]

There's a well defined way to access the heap and objects, it's called
JVMTI and JNI. They give you access to anything that such tools would
ever need, I think. Those are under our control.

Do you really think there are tools out there that do something more
esotheric like directly accessing memory to inspect objects (I want to
know them..)? It sounds to me like they already subscribed to a world
of unnecessary pain. Why should I care to make their world less
painful? :-D ;-) :-P

Roman

Am Dienstag, den 20.09.2016, 07:43 -0400 schrieb Christine Flood:
> I wouldn't.
> 
> There are a bazillion third party heap walking tools that assume they
> know the object layout.  
> Even if you got it working inside of Hotspot, the villagers would
> come for you with pitchforks and flaming torches.
> 
> 
> 
> Christine
> 
> 
> ----- Original Message -----
> > 
> > From: "Roman Kennke" <rkennke at redhat.com>
> > To: "Christine Flood" <chf at redhat.com>, "Aleksey Shipilev" <shade at r
> > edhat.com>
> > Cc: shenandoah-dev at openjdk.java.net
> > Sent: Tuesday, September 20, 2016 7:37:27 AM
> > Subject: Re: Design question: why not reuse the CMS slots in mark
> > word?
> > 
> > Am Dienstag, den 20.09.2016, 07:28 -0400 schrieb Christine Flood:
> > > 
> > > Here's some recent work on the cost of barriers in GC.
> > > 
> > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.231.3040
> > > &rep
> > > =rep1&type=pdf
> > > 
> > > You can see that a conditional read barrier is three times as
> > > expensive as a non-conditional read barrier.  Roman didn't
> > > believe me
> > > and insisted on testing it for himself and found the same result
> > > empirically ;-)
> > 
> > Yep :-)
> > 
> > Notice that this also precludes any form of side-table based
> > lookup.
> > 
> > All that said, I would love to see the brooks ptr 'inlined' in the
> > regular object layout. It may not actually be *that* complex
> > assuming
> > all code nicely respects the various base-offsets of object layout
> > (and
> > they must, right?) My idea would be to insert the brooks ptr right
> > before the object/array fields start (i.e. after the klass*). This
> > puts
> > it 2 words nearer to them and thus make it more likely to warm um
> > cache
> > for following field accesses. Plus, we'd loose less space with
> > compressed oops because we could squeeze a compressed brooks ptr
> > into
> > the unused 32bits of compressed klass* for regular objects (non-
> > arrays), and otherwise benefit from alignment.
> > 
> > I think I'll spend a day or two exploring that idea a little more.
> > 
> > Roman
> > 
> > > 
> > > 
> > > 
> > > Christine
> > > 
> > > 
> > > ----- Original Message -----
> > > > 
> > > > 
> > > > From: "Aleksey Shipilev" <shade at redhat.com>
> > > > To: "Christine Flood" <chf at redhat.com>
> > > > Cc: shenandoah-dev at openjdk.java.net
> > > > Sent: Tuesday, September 20, 2016 4:53:36 AM
> > > > Subject: Re: Design question: why not reuse the CMS slots in
> > > > mark
> > > > word?
> > > > 
> > > > On 09/19/2016 11:00 PM, Christine Flood wrote:
> > > > > 
> > > > > 
> > > > > The theory was to make the read barrier as efficient as
> > > > > possible.
> > > > > It's always just a single read of a fixed offset.  If we
> > > > > tried to
> > > > > reuse the mark word we'd have to deal with locked objects and
> > > > > hash
> > > > > codes and all that nonsense potentially making read barriers
> > > > > much
> > > > > more expensive.
> > > > > 
> > > > > If you have a protocol that uses the mark word and doesn't
> > > > > introduce
> > > > > extra overhead in the common case (a conditional in a read
> > > > > barrier
> > > > > would be deadly) I'd love to hear it.
> > > > 
> > > > Okay, that makes sense, thanks.
> > > > 
> > > > Is this a hunch about the read barriers cost, or we actually
> > > > tried
> > > > more
> > > > complicated read barriers? Trying to understand if potentially
> > > > worth
> > > > investigating, or this road was taken already.
> > > > 
> > > > Thanks,
> > > > -Aleksey
> > > > 
> > > > 
> >