RFR: 8168914: Crash in ClassLoaderData/JNIHandleBlock::oops_do during concurrent marking (original) (raw)

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Feb 16 18:07:43 UTC 2017

On 2/16/17 1:03 PM, Kim Barrett wrote:

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. I like the existance of a function but the "unsafe" wording in the API says that calling it is unsafe, not that the contents could be unsafe if they did something other than zero the oop.

So it's the API/name that I don't like.

We will have this API for a long time because we will need to remove things from the _handles list (ie. resolved_references for redefintion or mirrors if indirect mirrors are used).

thanks, Coleen

More information about the hotspot-dev mailing list