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