RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Reingruber, Richard]

Hi Robbin,

// taking the discussion back to the mailing lists

  > I still don't understand why you don't deoptimize the objects inside the 
  > handshake/safepoint instead?

This is unfortunately not possible. Deoptimizing objects includes reallocating
scalar replaced objects, i.e. calling Deoptimization::realloc_objects(). This
cannot be done at a safepoint or handshake.

1. The vm thread is not allowed to allocate on the java heap
   See for instance assertions in ParallelScavengeHeap::mem_allocate()
   https://github.com/openjdk/jdk/blob/4c73e045ce815d52abcdc99499266ccf2e6e9b4c/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp#L258

   This is not easy to change, I suppose, because it will be difficult to gc if
   necessary.

2. Using a direct handshake would not work either. The problem there is again
   gc. Let J be the JavaThread that is executing the direct handshake. The vm
   would deadlock if the vm thread waits for J to execute the closure of a
   handshake-all and J waits for the vm thread to execute a gc vm operation.
   Patricio Chilano made me aware of this: https://bugs.openjdk.java.net/browse/JDK-8230594

Cheers, Richard.

-----Original Message-----
From: Robbin Ehn <robbin.ehn at oracle.com> 
Sent: Mittwoch, 2. September 2020 13:56
To: Reingruber, Richard <richard.reingruber at sap.com>
Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Vladimir Kozlov <vladimir.kozlov at oracle.com>; David Holmes <david.holmes at oracle.com>
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

Hi,

I still don't understand why you don't deoptimize the objects inside the 
handshake/safepoint instead?

E.g.

JvmtiEnv::GetOwnedMonitorInfo you only should need the execute the code 
from:
eb.deoptimize_objects(MaxJavaStackTraceDepth)) before looping over the 
stack, so:

void
GetOwnedMonitorInfoClosure::do_thread(Thread *target) {
   assert(target->is_Java_thread(), "just checking");
   JavaThread *jt = (JavaThread *)target;

   if (!jt->is_exiting() && (jt->threadObj() != NULL)) {
+    if (EscapeBarrier::deoptimize_objects(jt, MaxJavaStackTraceDepth)) {
       _result = 
((JvmtiEnvBase*)_env)->get_owned_monitors(_calling_thread, jt, 
_owned_monitors_list);
     } else {
       _result = JVMTI_ERROR_OUT_OF_MEMORY;
     }
   }
}

Why try 'suspend' the thread first?


When we de-optimize all threads why not just in the following safepoint?
E.g.
VM_HeapWalkOperation::doit() {
+ EscapeBarrier::deoptimize_objects_all_threads();
...
}

Thanks, Robbin