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

Boehm, Hans hans.boehm at hp.com
Mon Nov 28 00:44:45 EST 2011


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.

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

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