[concurrency-interest] Unsafe publication of new objectsquestion

√iktor Klang viktor.klang at gmail.com
Tue Nov 16 08:59:33 EST 2010


>From my point of view the problem is allowing logic in the constructor.

On Mon, Nov 15, 2010 at 9:08 PM, David Holmes <davidcholmes at aapt.net.au>wrote:

> 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
> > >>
> > >
> > >
> >
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



-- 
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions <http://www.scalablesolutions.se>
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20101116/34c46f04/attachment-0001.html>


More information about the Concurrency-interest mailing list