RFR: 8258032: Reconsider LEAF entry restrictions

Coleen Phillimore coleenp at openjdk.java.net
Fri Jan 8 13:56:59 UTC 2021


On Fri, 8 Jan 2021 13:53:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Like the original changes, the most interesting stuff is in
>> interfaceSupport.inline.hpp. Just to keep it clear in my head:
>> - remove NoHandleMark helper from VM_LEAF_BASE; it gets added to JNI_LEAF and JVM_LEAF which need it; JRT_LEAF doesn't need it.
>> - remove ResetNoHandleMark helper from VM_ENTRY_BASE_FROM_LEAF since ThreadInVMfromNative will have one with your fix for JDK-8259374.
>> 
>> Please see my comment in JVM_ENTRY_FROM_LEAF.
>
> JRT_LEAF still has a NoSafepointVerifier if that helps.  There's a comment about the things it's not allowed to do in interfaceSupport.inline.hpp.  The things it's not supposed to do are all checked by the NSV.
> One of the things it can do now (especially if it's not going to safepoint) is to have a Handle with an enclosing HandleMark because GC won't touch the oops anyway.  This is one of the things @pron ran into with loom (see issue) and @fisk and I discussed.
> I originally took the bug because I was going to close it as WNF, because I hate removing restrictions.
> I do think there is a bug lurking here.  If you have a Handle without an enclosing HandleMark in JRT_LEAF, it will not be cleaned up when the leaf function returns.  This might need a HandleMarkCleaner.

I do not see fetch_unroll_info_helper reverting back to JRT_LEAF.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1990


More information about the hotspot-dev mailing list