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.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
>   
>