On Wed, 20 Mar 2024 02:10:28 GMT, Patricio Chilano Mateo
<[email protected]> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> review: correct one comment
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18332#discussion_r1531653123
