[concurrency-interest] The JSR-133 Cookbook for Compiler Writers

David Holmes davidcholmes at aapt.net.au
Fri Nov 25 01:12:24 EST 2011

Andrew Haley writes:
> OK, I see.  So, the only place you'd need this is in the cpu-specific
> code, and all the cpu-specific code is on arches that don't need
> StoreStore.

Actually no.  The C2 code for this is in shared code. See

void Parse::do_exits() {

  if (wrote_final()) {
    // This method (which must be a constructor by the rules of Java)
    // wrote a final.  The effects of all initializations must be
    // committed to memory before any code after the constructor
    // publishes the reference to the newly constructor object.
    // Rather than wait for the publication, we simply block the
    // writes here.  Rather than put a barrier on only those writes
    // which are required to complete, we force all writes to complete.
    // "All bets are off" unless the first publication occurs after a
    // normal return from the constructor.  We do not attempt to detect
    // such unusual early publications.  But no barrier is needed on
    // exceptional returns, since they cannot publish normally.

As already stated the MembarRelease will be a noop on x86 and sparc.

My thanks to Paul Hohenszee for tracking this code down.

I'm still searching for the C1 and interpreter versions of this.

David Holmes

> Thanks,
> Andrew.
> On 11/22/2011 03:56 PM, Nathan Reynolds wrote:
> > On x86 and Sparc TSO, the StoreStore barrier becomes a no-op.  (See the
> > table in the Multiprocessors section.)  These processors will not allow
> > stores to go before other stores.  Thus, the StoreStore barrier is
> > already enforced for all store operations by the processor.  The only
> > barrier required on x86 and Sparc TSO is the StoreLoad barrier.
> >
> > Nathan Reynolds
> > <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> > Consulting Member of Technical Staff | 602.333.9091
> > Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> >
> > On 11/22/2011 7:40 AM, Andrew Haley wrote:
> >> A little mystery:
> >>
> >> Inserting Barriers
> >> ...
> >>
> >>     2. Issue a StoreStore barrier after all stores but before return
> >>     from any constructor for any class with a final field.
> >>
> >> So, I'm looking for this barrier in the HotSpot code but I have been
> >> unable to find it.  Can someone please put me out of my misery and
> >> tell me where it is?
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list