RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Reingruber, Richard
richard.reingruber at sap.com
Wed Sep 2 13:48:12 UTC 2020
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
More information about the serviceability-dev
mailing list