Hi Richard, as mentioned it would be better if you could do this with
handshakes, instead of using _suspend_flag (since they are going away).
But I can't think of a way doing it without blocking safepoints, so we need to
add some more features in handshakes first.
When possible I hope you are willing to move this code to handshakes instead.
You could stop one thread with, e.g.:
class EscapeBarrierSuspendHandshake : public HandshakeClosure {
Semaphore _is_waiting;
Semaphore _wait;
bool _started;
public:
EscapeBarrierSuspendHandshake() : HandshakeClosure("EscapeBarrierSuspend"),
_wait(0), _started(false) { }
void do_thread(Thread* th) {
_is_waiting.signal();
_wait.wait();
Atomic::store(&_started, true);
}
void wait_until_eb_stopped() { _is_waiting.wait(); }
void start_thread() {
_wait.signal();
while(!Atomic::load(&_started)) {
os::naked_yield();
}
}
};
But it would block safepoints.
Thanks, Robbin
On 12/10/19 10:45 PM, Reingruber, Richard wrote:
Hi,
I would like to get reviews please for
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
Corresponding RFE:
https://bugs.openjdk.java.net/browse/JDK-8227745
Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915
And potentially https://bugs.openjdk.java.net/browse/JDK-8214584 [1]
Vladimir Kozlov kindly put webrev.3 through tier1-8 testing without issues
(thanks!). In addition the
change is being tested at SAP since I posted the first RFR some months ago.
The intention of this enhancement is to benefit performance wise from escape
analysis even if JVMTI
agents request capabilities that allow them to access local variable values.
E.g. if you start-up
with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, then escape
analysis is disabled right
from the beginning, well before a debugger attaches -- if ever one should do
so. With the
enhancement, escape analysis will remain enabled until and after a debugger
attaches. EA based
optimizations are reverted just before an agent acquires the reference to an
object. In the JBS item
you'll find more details.
Thanks,
Richard.
[1] Experimental fix for JDK-8214584 based on JDK-8227745
http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.patch
