RFR(s): 8228758: assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Wed Sep 4 13:48:36 UTC 2019



On 9/4/19 5:14 AM, Robbin Ehn wrote:
>
>>> As we do with safepoints, NoSafepointVerifier (since it covers both 
>>> cases).
>>
>> The NoSafepointVerifier is in the JRT_LEAF but not in VM_LEAF_BASE, 
>> which is also used by JNI_LEAF and JVM_LEAF.  I believe it should be 
>> moved there (not with this patch).
>>
>
> Can you track these suggested changes :)

Okay, I'll file some RFEs.  I also started a private repo to get rid of 
HandleMark completely in favor of Handles destroying themselves. For 
three reasons:

- There are HandleMarks (and associated ResetNoHandleMarks) where there 
aren't any oops being handled.  These were left over from permgen.  A 
lot were removed but this RFR made me find plenty that are left over.  
It's sort of a non-trivial exercise to remove the unnecessary ones.  I 
added an assert in the HandleMark destructor to assert that the number 
of Handles was zero and hit a lot, but it might not be zero on all call 
paths.

- HandleMarks make it possible to keep oops alive that have gone out of 
scope because they keep a pointer to the Handle in the thread for GC 
until the ~HandleMark.

- Trying to explain HandleMark to somebody new on the project makes 
people give you funny looks.  Every now and then, I see some new code 
add one because there's also a ResourceMark.

I went through this exercise with methodHandles and constantPoolHandles, 
because they were originally cleaned up with HandleMark.   In order to 
remove HandleMark, we have to pass Handle by const reference everwhere.

For the most part, in runtime, we _should_ have limited dealings with 
oops outside of handles.  We either create an oop, or get one from a 
jobject, and immediately handle it and pass that same handle around.  I 
believe the implicit oop -> Handle converting constructor is gone.  But 
there is a lot of this in jvmci so we'd have to assess the performance 
impact of this change.

Anyway, thank you for removing this distinction.  Now one doesn't have 
to go back and figure out why it's "QUICK".

Thanks,
Coleen

>
> /Robbin
>
>> Coleen
>>>
>>> /Robbin
>>>
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>>
>>>>>>> Thanks, Robbin
>>>>>>>
>>>>>>> Some extra words about NoHandleMark:
>>>>>>> I believe NoHandleMark should be removed.
>>>>>>> In the LEAF case, there is no point in creating a Handle within a
>>>>>>> NoSafepointVerifier, since we don't safepoint.
>>>>>>> The other usecase seems to be, I'm in java don't do VM things, 
>>>>>>> and someone tried
>>>>>>> to protected that with a NoHandleMark. There many ways to create 
>>>>>>> a much more
>>>>>>> robust check for that.
>>>>>>> But a discussion for another time.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Issue:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8228758
>>>>>>>>>
>>>>>>>>> Changeset:
>>>>>>>>> http://cr.openjdk.java.net/~rehn/8228758/webrev/
>>>>>>>>>
>>>>>>>>> Passes t1-3 (and performance benchmarks)
>>>>>>>>>
>>>>>>>>> Thanks, Robbin
>>



More information about the hotspot-runtime-dev mailing list