RFR(s): 8228758: assert(_no_handle_mark_nesting == 0) failed: allocating handle inside NoHandleMark
Robbin Ehn
robbin.ehn at oracle.com
Wed Sep 4 09:12:30 UTC 2019
>
> I agree with you Dan - the analogy is somewhat off. The reasons for deferring
> safepoints in a region are quite simple to know and express and enforce - and
> basically amount to "if I hit a safepoint GC might touch stuff I'm using". The
> actual safepoint just causes blocking which is in general benign to the thread.
> In contrast handshakes cause the current thread to start executing arbitrary
> code with no regard for the code that was being executed. That's much harder to
> account for. My biggest concern is locking itself, which must include polls, but
> then handshake code might call into the locking code again.
>
Yes, I agree, the locking is the major concern here.
Since the subsystem must be access as normal (outside a safepoint).
With safepoint we often by-pass locking to get around the issue.
So the subsystems are often not re-entrant, it's just safepoint re-entrant.
/Robbin
>> In any case, I'm going to hold off on reviewing the code since I think
>> you're still considering making changes based on David's last set of
>> comments...
>
> I don't think any changes are pending/under-consideration. I gave the okay on
> making the proposed changes, we're just discussing some of the motivations.
>
> Cheers,
> David
>
>> Dan
>>
>>
>>
>>>
>>>>
>>>>> This changes the polling model a bit and we have not proper look at this.
>>>>> Maybe we should add the constraints to the poll and to find any potential
>>>>> troublesome polls.
>>>>
>>>> I'm not sure how we would discover the problems until we have a handshake
>>>> that executes some code that violates a constraint. The constraints
>>>> themselves are not obvious. Subsystems do not clearly identify themselves as
>>>> being reentrant or not - most things are not reentrant by their nature.
>>>
>>> As we do with safepoints, NoSafepointVerifier (since it covers both cases).
>>>
>>> /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