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

[Rob McKenna]

This appears to have been pushed without a corresponding push approval
request. Please file one retroactively.

    -Rob

On 10/07/18 12:40, David Holmes wrote:
> 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
>