RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking (original) (raw)
Kim Barrett kim.barrett at oracle.com
Thu Feb 16 18:03:14 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 9:13 AM, Erik Helin <erik.helin at oracle.com> wrote:
On 02/15/2017 10:08 PM, coleen.phillimore at oracle.com wrote:
Why is
629 void ClassLoaderData::removehandleunsafe(jobject h) {
it called unsafe? It is safe to zero the element in the block, isn't it? Because code using removehandleunsafe should be cautious. It is only safe to write NULL to the ((oop) op) if: - the jobject originates from a call to ClassLoaderData::addhandle (the assert verifies this). - *op is the sole remaining pointer to **op (the object). - The native memory backing the chunked linked list is not freed. It is unfortunate that we even need to have the removehandleunsafe at all. An alternative is to let the only code using removehandleunsafe (ModuleEntry) do ((oop) op) = NULL on its own. Would you prefer that?
I think I prefer the (hopefully temporary?) API wart of this special function.
- 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 ]