RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking

[Kim Barrett]

> On Feb 15, 2017, at 10:31 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> If I may ...
> 
> On 16/02/2017 12:41 PM, Kim Barrett wrote:
>>> On Feb 15, 2017, at 10:07 AM, Erik Helin <erik.helin at oracle.com> wrote:
>>> 
>>> On 02/15/2017 02:48 AM, David Holmes wrote:
>>>> Hi Erik,
>>> 
>>> Hi David,
>>> 
>>> thanks for having a look! Please see new patches at:
>>> - incremental: http://cr.openjdk.java.net/~ehelin/8168914/00-01/
>>> - full: http://cr.openjdk.java.net/~ehelin/8168914/01/
>> 
>> ------------------------------------------------------------------------------
>> /src/share/vm/classfile/classLoaderData.cpp
>> 138     const juint size = OrderAccess::load_acquire(&c->size);
>> 
>> I think all but the first chunk have a constant size of the
>> maximum size, so no need for acquire except for the first.
> 
> The size is incremented on each add, so this acquire sync's with the release of the new size, so that we are sure to see the oop that was just added.
> 
> Though given the races between add and oops_do it may not actually matter.

By “first” I mean the first chunk.  only the first chunk’s size is subject to modification.  The release_store of _head that made the first chunk accessible will be after the setting of the next chunk’s size to its final (max) value.  The corresponding load_acquire of _head ensures any _next chunks are visibly complete.  It’s the same rationale for _next not requiring any special handling. At least, that’s how it looks to me right now; am I missing something.