RFR (S) 8078438: Interpreter should support conditional card marks (UseCondCardMark)

Andrew Haley aph at redhat.com
Tue Apr 28 16:23:26 UTC 2015


Hi,

On 04/28/2015 04:54 PM, Thomas Schatzl wrote:
> 
> I dug a little through the CMS code, and I think the preclean code
> mentioned is actually something like this:
> 
> {
> MutexLocker x(some-lock); // In the CMSTockenSync constructor
> }
> 
> MemRegion range = find next range of dirty cards by scanning the card
> table
> 
> write 0x1 to range
> 
> {
> MutexLocker x(some-lock); // In the CMSTockenSync destructor
> }
> 
> inspect all object references in range x
> 
> See CMSCollector::preclean_card_table().
> 
> I.e. the implicit barriers (the CAS'es) executed by acquiring the
> mutexes in the preclean thread provide the necessary synchronization
> (actually between reading the card and inspecting the memory there are a
> few of them).
> 
> I am not sure if this was the intention of using these MutexLockers (I
> doubt that) but it seems sufficient.

Yes, I think it does.  Well, kinda-sorta.  Monitor::IUnlock() does a
storeload barrier which isn't really enough, but storeload is
implemented as a full barrier on every processor I've come across so
it'll do.  It's not a nice thing to depend on, though.  But if there
is another lock/unlock after the unlock in the CMSTockenSync
destructor then we're golden even on those processors I've never come
across.

So we could make conditional card marking the default and use STLRB
(or DMB ST?  Might be better).  I really don't want to emit
unnecessary store barriers.

One other thing: do other GCs need this releasing store?

Thanks,
Andrew.


More information about the hotspot-gc-dev mailing list