[9] RFR (XS): 8138922: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list

[David Holmes]

On 11/02/2016 8:56 PM, Andrew Haley wrote:
> On 10/02/16 18:13, Vladimir Ivanov wrote:
>> The fix is to insert a StoreStore barrier before registering an object
>> on the list.
>
> 1.  There's not usually any point having a StoreStore without a
> corresponding load barrier on the reader side: there's nothing for the
> StoreStore to synchronize with.  Having said that, you could argue
> that because there's an address dependency from the list pointer to
> all the instances of StubCodeDesc we should be safe.

That was my take as well.

I could not see where the iteration code actually exists. If there were 
a list() accessor then we could add a loadload into that (or convert to 
load_acquire with store_release).

David
-----

> 2.  StoreStore is arguably wrong for everything except an object
> initialized with pure constants.  However, given that a StubCodeDesc
> is immutable I guess it's safe, as Hans observes in [1].
>
> Acquire/release is much easier to reason about because you don't have
> to make these fine judgements, so I'd just use acquire/release
> everywhere in order to keep my sanity.
>
> Andrew.
>
>
> [1] http://www.hboehm.info/c++mm/no_write_fences.html
>