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

[Daniel D. Daugherty]

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
>