RFR: 8328285: GetOwnedMonitorInfo functions should use JvmtiHandshake [v2]

Serguei Spitsyn sspitsyn at openjdk.org
Wed Mar 20 08:14:22 UTC 2024


On Wed, 20 Mar 2024 02:10:28 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> 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


More information about the serviceability-dev mailing list