RFR: 8255233: InterpreterRuntime::at_unwind should be a JRT_LEAF [v2]

Erik Österlund eosterlund at openjdk.java.net
Tue Oct 27 13:38:25 UTC 2020


On Tue, 27 Oct 2020 01:14:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Erik Österlund has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address cast
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 1177:
> 
>> 1175: JRT_LEAF(void, InterpreterRuntime::at_unwind(JavaThread* thread))
>> 1176:   // JRT_END does an implicit safepoint check, hence we are guaranteed to block
>> 1177:   // if this is called during a safepoint
> 
> The comments are no longer valid. The implicit safepoint check came from the use of ThreadInVMfromJava as part of the JRT_ENTRY.
> 
> Also it is far from obvious that  StackWatermarkSet::before_unwind meets all the requirements of a JRT_LEAF method. Please assure me it is. :)

Nice catch. I removed the out of date comments.
Regarding the leafness of the operation: the operations performed in the stack watermark are indeed designed to run in such conditions. When the callbacks are executed, verification code is run, asserting we are not in a state ignored by the GC. It would never work to have code that transitions inside of such callbacks. Today, it merely applies some GC barriers, similar to performing an access API call.
Having said that, despite not transitioning in this code path, I do make the stack walkable when calling this method, so that the barrier can see what the last_Java_frame is, and figure out if action needs to be taken or not. But we do that for other leaf functions as well, and that is fine. The crucial thing is that there are zero transitions, which I can assure you of. In particular, the thread will be _in_java throughout the entire operation.

Thanks for the review!

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

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


More information about the hotspot-dev mailing list