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

[David Holmes]

On 10/07/2018 12:42 AM, Andrew Haley wrote:
> 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?

Looks good. Thank you.

David