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

[coleen.phillimore at oracle.com]

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::remove_handle_unsafe(jobject h) {
>>>
>>>
>>> it called unsafe?  It is safe to zero the element in the block, isn't it?
>> Because code using remove_handle_unsafe should be cautious. It is only safe to write NULL to the *((oop*) op) if:
>> - the jobject originates from a call to ClassLoaderData::add_handle
>>   (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 remove_handle_unsafe at all. An alternative is to let the only code using remove_handle_unsafe (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
>