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

Roman Kennke rkennke at redhat.com
Tue Sep 20 11:37:27 UTC 2016


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


More information about the shenandoah-dev mailing list