[concurrency-interest] Unsafe publication of new objectsquestion

Andrew Trick andrew.trick at gmail.com
Mon Nov 15 13:20:22 EST 2010


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