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

[Robbin Ehn]

Hi Richard,

On 2020-09-02 15:48, Reingruber, Richard wrote:

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?

So for handshakes using asynch handshake and allowing blocking inside
would fix that. (future fix, I'm working on that now)

For safepoint, since we have suspended all threads, ~'safepointed them'
with a JavaThread, you _could_ just execute the action directly (e.g.
skipping VM_HeapWalkOperation safepoint) since they are suppose to be
safely suspended until the destructor of EB, no?

So I suggest future work to instead just execute the safepoint with the
requesting JT instead of having a this special safepoiting mechanism.

Since you are missing above functionality I see why you went this way.
If you need to push it, it's fine by me.

Thanks for explaining once again :)

/Robbin

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://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c73e045ce815d52abcdc99499266ccf2e6e9b4c/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp*L258__;Iw!!GqivPVa7Brio!K0f5chjtePI6MKBSBOoBKya9YZTJlVhsExQYMDO96v3Af_Klc_E4R26_dSyowotF$

    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....@oracle.com>
Sent: Mittwoch, 2. September 2020 13:56
To: Reingruber, Richard <richard.reingru...@sap.com>
Cc: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Vladimir Kozlov 
<vladimir.koz...@oracle.com>; David Holmes <david.hol...@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