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

[Robbin Ehn]

Thanks Dan!

/Robbin

On 2019-09-04 17:48, Daniel D. Daugherty wrote:
> On 8/29/19 8:48 AM, Robbin Ehn wrote:
>> Hi all, please review.
>>
>> The JNI_QUICK_ENTRY/JVM_QUICK_ENTRY skips creating the HandleMarkCleaner, 
>> instead they have a NoHandleMark. Handshakes can be executed by the JavaThread
>> itself, thus might require a HandleMark. QUICK entries allow polls for
>> safepoint/handshakes, if a handshake is executed and a HandleMark is created we
>> hit this assert.
>>
>> HandleMarkCleaner have previous been optimized for inlining, thus cheap.
>> Performance benchmarks shows no benefit of not allowing HandleMark.
>>
>> This changeset removes the the QUICK entry and avoids this issue.
>>
>> Note that JNI_QUICK_ENTRY also don't have WeakPreserveExceptionMark,
>> so it's changed to JNI_ENTRY_NO_PRESERVE.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8228758
>>
>> Changeset:
>> http://cr.openjdk.java.net/~rehn/8228758/webrev/
> 
> src/hotspot/share/runtime/interfaceSupport.inline.hpp
>      No comments.
> 
> src/hotspot/share/prims/jvm.cpp
>      So JVM_QUICK_ENTRY switches to JVM_ENTRY here which means a
>      switch from NoHandleMark to HandleMarkCleaner.
> 
> src/hotspot/share/prims/jni.cpp
>      So JNI_QUICK_ENTRY switches to JNI_ENTRY_NO_PRESERVE here which
>      means a switch from NoHandleMark to HandleMarkCleaner.
> 
> Re: The why did we have QUICK wrappers discussion? If I remember my
> history correctly, we had QUICK wrappers as a way to mark code that
> didn't need to go through the expense of have a HandleMarkCleaner.
> I have a memory of them being more expensive in the long past...
> something like stack walking backwards to find the enclosing
> HandleMark or something like that. They were subsequently modified
> to be cheaper, but we didn't drop the concept of a QUICK wrapper.
> 
> A QUICK wrapper has the advantage of forcing the code that it wraps
> to be simpler. Typically, if you can't have a Handle to wrap an oop,
> then you can't do something that goes to a safepoint like grabbing a
> lock. Conversely, the QUICK wrapper is a limitation and sometimes we
> went through backward handsprings to try to make some bit of code
> work when it would be so much simpler if we could create a Handle.
> 
> Looks like Robbin has done due diligence here with performance testing
> the switch from NoHandleMark to HandleMarkCleaner. I don't think the
> Tier1-3 testing is going to get us a whole lot of -Xcomp coverage (if
> any_ so we'll need to keep our eyes open as this changeset makes its
> way to the higher tiers.
> 
> Thumbs up!
> 
> Dan
> 
> 
>>
>> Passes t1-3 (and performance benchmarks)
>>
>> Thanks, Robbin
>>
>