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

[Andrew Haley]

On 07/09/2018 02:46 AM, David Holmes wrote:
> 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.

Not entirely, but never mind.  I have a crash in production, so I will
do what it takes to get a fix accepted.

>> 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.

http://cr.openjdk.java.net/~aph/8206406-2/

OK?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671