On 14/09/2020 6:18 pm, Richard Reingruber wrote:
On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes <dhol...@openjdk.org> wrote:
Hi,
this is the continuation of the review of the implementation for:
https://bugs.openjdk.java.net/browse/JDK-8227745
https://bugs.openjdk.java.net/browse/JDK-8233915
It allows for JIT optimizations based on escape analysis even if JVMTI agents
acquire capabilities to access references
to objects that are subject to such optimizations, e.g. scalar replacement. The
implementation reverts such
optimizations just before access very much as when switching from JIT compiled
execution to the interpreter, aka
"deoptimization". Webrev.8 was the last one before before the transition to
Git/Github:
http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
Thanks, Richard.
src/hotspot/share/compiler/compileBroker.cpp line 831:
829: MonitorLocker ml(dt, EscapeBarrier_lock,
Mutex::_no_safepoint_check_flag);
830: static int single_thread_count = 0;
831: enter_single_loop = single_thread_count++ <
DeoptimizeObjectsALotThreadCountSingle;
The update to `single_thread_count` is not atomic.
I think it is atomic because it is never accessed without holding
EscapeBarrier_lock
Doh! My bad.
David
-------------
PR: https://git.openjdk.java.net/jdk/pull/119
