RFR: 8206406: StubCodeDesc constructor publishes partially-constructed objects on StubCodeDesc::_list

[David Holmes]

On 7/07/2018 1:43 AM, Andrew Haley wrote:
> On 07/06/2018 03:50 PM, Martin Buchholz wrote:
>> (but memory_order_consume has not been successful.)
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
> 
> Sure, but I don't think that matters for this case.  While consume is
> a problem for the C Standard, the Linux kernel has its own memory
> model which makes extensive use of consume.  This works because
> there's more control over the systems on which the kernel runs than
> there is for C in general: the same is true for us.  Bear in mind that
> this bug has been present for years.

But this isn't Linux only code and load-acquire should always pair with 
a release-store! That's the basic programming model for this stuff in 
hotspot.

> 
> The first rule for back-porting is "do no harm."  I can be sure that
> this patch does no harm, but I cannot be sure of a more complex back-
> port.

I don't think I can recall any occurrence where adding a memory-barrier 
introduced a functional bug. So I see no opportunity for harm here. I 
can see the possibility for harm from a missing memory barrier though.

David