RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
David Holmes
david.holmes at oracle.com
Tue Sep 15 01:35:12 UTC 2020
On 14/09/2020 6:18 pm, Richard Reingruber wrote:
> On Mon, 14 Sep 2020 04:57:21 GMT, David Holmes <dholmes at 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
>
More information about the serviceability-dev
mailing list