Hi Richard,
On 7/09/2019 12:24 am, Reingruber, Richard wrote:
Hi,
could I please get reviews for
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230677/webrev.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8230677
The JVMTI functions GetOwnedMonitorInfo() and GetOwnedMonitorStackDepthInfo()
can be used to
retrieve objects locked by a thread. In terms of escape analysis those
references escape and
optimizations like scalar replacement become invalid.
What bothers me about this is that it seems like escape analysis is
doing something wrong in this case. If the object is thread-local but is
being synchronized upon then either:
a) the synchronization is elided and so the object will not appear in
the set of owned monitors; or
b) the fact synchronization occurs renders the object ineligible to be
considered thread-local, and so there is no problem with it appearing in
the set of owned monitors
I think there is a bigger design philosophy issue here about the
interaction of escape analysis and debugging/management frameworks in
general. I'd like to see a very clear description on exactly how they
should interact.
Cheers,
David
The runtime currently cannot cope with objects escaping through JVMTI (try
included
tests). Therefore escape analysis should be disabled if an agent requests the
capabilities
can_get_owned_monitor_info or can_get_owned_monitor_stack_depth_info.
This was taken out of JDK-8227745 [1] to make it smaller. With JDK-8227745
there's no need to
disable escape analysis, instead optimizations based on escape analysis will be
reverted just before
objects escape through JVMTI.
I've run tier1 tests.
Thanks, Richard.
[1] https://bugs.openjdk.java.net/browse/JDK-8227745
