On Wed, 13 Aug 2025 06:03:38 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> simplified after feedback
>
> src/hotspot/share/prims/jvmtiExport.cpp line 1839:
>
>> 1837: JRT_BLOCK
>> 1838: state = get_jvmti_thread_state(thread);
>> 1839: JRT_BLOCK_END
>
> The `JRT_BLOCK` is defined as:
>
> #define JRT_BLOCK \
> { \
> assert(current == JavaThread::current(), "Must be"); \
> ThreadInVMfromJava __tiv(current); \
> JavaThread* THREAD = current; /* For exception macros. */ \
> DEBUG_ONLY(VMEntryWrapper __vew;)
>
>
> I'd suggest something like this instead of using `JRT_BLOCK`:
>
> - JvmtiThreadState *state = get_jvmti_thread_state(thread);
> + JvmtiThreadState *state = nullptr;
> + {
> + ThreadInVMfromJava __tiv(thread);
> + state = get_jvmti_thread_state(thread);
> + }
>
>
> Alternatively, the `JRT_BLOCK` can be started at the line 1837 and ended with
> `JRT_BLOCK_END` at the line 1875. Not sure, what issue we can encounter with
> this though. At least, it is worth a try.
As I understand the post_method_entry was called via JRT_BLOCK_ENTRY and not
JRT_BLOCK by the reason. We need to be in Java. See comments for the method
invocation.
// This is a JRT_BLOCK_ENTRY because we have to stash away the return oop
// before transitioning to VM, and restore it after transitioning back
// to Java. The return oop at the top-of-stack, is not walked by the GC.
JRT_BLOCK_ENTRY(void, InterpreterRuntime::post_method_exit(JavaThread* current))
LastFrameAccessor last_frame(current);
JvmtiExport::post_method_exit(current, last_frame.method(),
last_frame.get_frame());
JRT_END
And thanks for simplification, it is a good idea. I've updated the PR.
I am running tier1-8 for Hotspot tests to ensure that nothing is broken.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26713#discussion_r2272174407
