[concurrency-interest] Unsafe publication of new objectsquestion

Andrew Trick andrew.trick at gmail.com
Tue Nov 16 13:38:11 EST 2010


I read Joseph's question as "how does one implement a JVM that meets
the JVM spec". Maybe this wasn't the best forum for that discussion?

I think David answered your question to the effect that it's the
programmer's responsibility to synchronize constructors in general,
but final fields have some implied synchronization.

-Andy

On Tue, Nov 16, 2010 at 5:59 AM, √iktor Klang <viktor.klang at gmail.com> wrote:
> 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
> Code:   github.com/viktorklang
> Follow: twitter.com/viktorklang
> Read:   klangism.tumblr.com
>
>



More information about the Concurrency-interest mailing list