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

David Holmes davidcholmes at aapt.net.au
Mon Nov 28 02:18:48 EST 2011


Hi Hans,

Hans Boehm writes:
> How is the method table pointer any different from any other
> final field here?  This code looks like the fence is not
> generated if the method table pointer is written, but there are
> no other final fields.  I can't at the moment think of a way to
> defend that choice.

A Java object contains a reference to its class, which in turn holds the
vtable pointer. That class reference may be stored using "release
semantics". I say "may" because the code is somewhat complex and its hard to
know exactly what paths will be executed just be reading the code.

>From a practical perspective this is only an issue for non-TSO systems when
the object reference is subject to unsafe publication. Even for non-TSO
systems the "distance" between the two stores makes it unlikely (and no I
can't quantify that) they will be reordered.

The constructor executes after that, so any final field assignments there
need their own release barrier.

> Presumably the initial zeroing is handled separately be
> pre-clearing memory returned from the GC, and putting a fence
> after the bulk-clearing operation?

Also a complex story, but the store to the class reference can act as a
barrier for both.

David
-----

> Hans
>
> > -----Original Message-----
> > From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-
> > interest-bounces at cs.oswego.edu] On Behalf Of David Holmes
> > Sent: Thursday, November 24, 2011 10:12 PM
> > To: Andrew Haley; Nathan Reynolds
> > Cc: concurrency-interest at cs.oswego.edu
> > Subject: Re: [concurrency-interest] The JSR-133 Cookbook for Compiler
> > Writers
> >
> > 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
> > share/vm/opto/parse1.cpp
> >
> > 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.
> >     //
> >     _exits.insert_mem_bar(Op_MemBarRelease);
> >
> > 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
> > >
> >
> > _______________________________________________
> > 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