RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking (original) (raw)
Kim Barrett kim.barrett at oracle.com
Thu Feb 16 07:46:01 UTC 2017
- Previous message: RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking
- Next message: RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Feb 16, 2017, at 2:41 AM, David Holmes <david.holmes at oracle.com> wrote:
On 16/02/2017 3:53 PM, Kim Barrett wrote:
/src/share/vm/classfile/classLoaderData.cpp 138 const juint size = OrderAccess::loadacquire(&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 oopsdo it may not actually matter. By “first” I mean the first chunk. only the first chunk’s size is subject to modification. The releasestore 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 loadacquire 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. The head chunk has its size incremented on each add(). David
Agreed, and a load_acquire is needed for the _head chunk.
I’m suggesting an ordinary load is sufficient for any _next chunks as we loop down the list.
- Previous message: RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking
- Next message: RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]