On Wed, 20 Mar 2024 08:12:06 GMT, Serguei Spitsyn <[email protected]> wrote:
>> src/hotspot/share/prims/jvmtiEnv.cpp line 1368:
>>
>>> 1366: if (java_thread != nullptr) {
>>> 1367: Handle thread_handle(calling_thread, thread_oop);
>>> 1368: EscapeBarrier eb(true, calling_thread, java_thread);
>>
>> I see that now we will execute the EscapeBarrier code for the vthread case
>> too. We actually had to disable that for virtual threads since it doesn't
>> work (8285739 and 8305625). But we only addressed the case when targeting
>> all threads and not the single thread one. We would need to add the same
>> check in EscapeBarrier::deoptimize_objects(int d1, int d2) to skip a thread
>> with mounted continuation.
>
> Good suggestion, thanks!
> Would the following fix work ? :
>
>
> git diff
> diff --git a/src/hotspot/share/runtime/escapeBarrier.cpp
> b/src/hotspot/share/runtime/escapeBarrier.cpp
> index bc01d900285..1b6d57644dc 100644
> --- a/src/hotspot/share/runtime/escapeBarrier.cpp
> +++ b/src/hotspot/share/runtime/escapeBarrier.cpp
> @@ -75,7 +75,7 @@ bool EscapeBarrier::deoptimize_objects(int d1, int d2) {
> // These frames are about to be removed. We must not interfere with that
> and signal failure.
> return false;
> }
> - if (deoptee_thread()->has_last_Java_frame()) {
> + if (deoptee_thread()->has_last_Java_frame() &&
> deoptee_thread()->last_continuation() == nullptr) {
> assert(calling_thread() == Thread::current(), "should be");
> KeepStackGCProcessedMark ksgcpm(deoptee_thread());
> ResourceMark rm(calling_thread());
>
>
> BTW, it seems the `PopFrame` and the `ForceEarlyReturn<RetType>` are broken
> the same way and, I hope, the fix above should solve the issue.
Fix looks good.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1532363608
