[concurrency-interest] Unsafe publication of new objectsquestion

David Holmes davidcholmes at aapt.net.au
Mon Nov 15 15:08:55 EST 2010


Andy,

The VM is required to "do the right thing" here. Only by examining an actual
VM implementation can you determine how it achieves this, and ensure that it
does achieve it.

David

> -----Original Message-----
> From: Andrew Trick [mailto:andrew.trick at gmail.com]
> Sent: Tuesday, 16 November 2010 4:20 AM
> To: dholmes at ieee.org
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Unsafe publication of new
> objectsquestion
>
>
> Not arguing at all. But I don't want JVM implementers and
> microarchitects to completely ignore the issue...  optimized object
> allocation will not involve thread transitions. Pre-zeroing is also
> not efficient, but moot because the JVM will likely need to do
> type-specific initialization of the object header (exposing a zero
> header == crash). Furthermore, the allocating thread need not do any
> loads to publish a newly instantiated object. It just needs to store
> the pointer in a field, not necessarily declared volatile. Any pointer
> store between instantiation and the next barrier may be a publisher
> (considering only the first publisher is insufficient). So an explicit
> barrier is needed, resulting in some type of fence on non-TSO
> machines. Hardware support for a reasonably efficient store-store
> fence is great to have for this purpose.
> -Andy
>
> On Fri, Nov 12, 2010 at 9:02 PM, David Holmes
> <davidcholmes at aapt.net.au> wrote:
> > Andrew Trick writes:
> >>
> >> I thought the original question referred to object instantiation, not
> >> the call to <init>. Setting up the object header and zeroing fields
> >> obviously requires a barrier.
> >
> > The original question was somewhat vague.
> >
> > The JMM requires that you always see at worst a default
> initialized object,
> > so yes there are some implicit barriers in there, but the
> details depend on
> > the VM implementation. Pre-zeroing the heap avoids the need for explicit
> > zeroing at object allocation. Thread transitions to/from Java/VM code
> > provide implicit (and sometimes explicit) barrier effects that avoid the
> > need for an explicit barrier as part of the object allocation and
> > initialization sequence.
> >
> > On some architectures the theoretical problem of being able to see a
> > reference to the object before seeing the initialized fields
> can't happen
> > anyway (at the hardware level) due to dependent-loads (as Joe
> Seigh alluded
> > to in the original post).
> >
> > Cheers,
> > David
> >
> >> -Andy
> >>
> >> On Fri, Nov 12, 2010 at 7:12 PM, David Holmes
> >> <davidcholmes at aapt.net.au> wrote:
> >> > Justin T. Sampson writes:
> >> >> On Fri, Nov 12, 2010 at 2:16 PM, David Holmes
> >> <davidcholmes at aapt.net.au>
> >> > wrote:
> >> >>> Andrew Trick writes:
> >> >>> > The JVM needs an effective store-store memory barrier between all
> >> >>> > stores that initialize a new object and any store that
> may publish a
> >> >>> > pointer to it. Not easy to do efficiently on all architectures.
> >> >>>
> >> >>> The JVM would need this if it were to guarantee
> >> safe-publication, but it
> >> >>> doesn't guarantee that.
> >> >>
> >> >>
> >> >> It does for final fields, right? Or is that a different concept?
> >> >
> >> > There are additional guarantees regarding the initialization of final
> >> > fields. I suggest reading Section 17.5 of the Java Language
> >> Specification
> >> > for the details, but for a simple formulation see the "Final
> >> Fields" section
> >> > of the JMM Cookbook:
> >> >
> >> > http://gee.cs.oswego.edu/dl/jmm/cookbook.html
> >> >
> >> > Cheers,
> >> > David Holmes
> >> >
> >> > _______________________________________________
> >> > 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