RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken

[Daniel D. Daugherty]

I'm good with the testing that you've done. Thanks for closing the loop.
Serguei?

Dan


On 9/26/19 3:36 AM, Reingruber, Richard wrote:
>
> Hi Dan and Serguei,
>
> The change went through our nightly testing a few times, which 
> includes these tests and many more on all platforms.
>
> Thanks, Richard.
>
> *From:*serguei.spitsyn at oracle.com <serguei.spitsyn at oracle.com>
> *Sent:* Mittwoch, 25. September 2019 19:10
> *To:* daniel.daugherty at oracle.com; Reingruber, Richard 
> <richard.reingruber at sap.com>; Vladimir Kozlov 
> <vladimir.kozlov at oracle.com>; David Holmes <david.holmes at oracle.com>; 
> hotspot-compiler-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> *Subject:* Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI 
> capability can_get_owned_monitor_info was taken
>
> Hi Dan and Richard,
>
> The JVMTI and JDI tests are:
>   vmTestbase_nsk_jvmti, vmTestbase_nsk_jdi and jdk_jdi
>
> The tests locations are:
> open/test/hotspot/jtreg/vmTestbase/nsk/jvmti
> open/test/hotspot/jtreg/vmTestbase/nsk/jdi
>   open/test/jdk/com/sun/jdi
>
> I think, they all have to be in the hs-tier5-rt.
>
> Thanks,
> Serguei
>
>
> On 9/25/19 07:32, Daniel D. Daugherty wrote:
>
>     Based on the review thread, it looks like Richard has run Tier1
>     tests on
>     this change. I don't think there are any JVM/TI tests in Tier1.
>     I'm not
>     sure how much compiler testing is done in Tier1, but I do know
>     that the
>     compiler stress testing doesn't kick in until the later tiers
>     (Tier5 or
>     Tier6)...
>
>     Serguei, with your JVM/TI hat on, what kind of additional testing
>     (if any)
>     do you think we need here?
>
>     Dan
>
>
>     On 9/25/19 6:20 AM, Reingruber, Richard wrote:
>
>         Thank you Vladimir and also David and Serguei for your Reviews.
>
>            > May be add comment that it is onload capability and can't
>         be changed during execution.
>
>         Done.
>
>         I'll be out-of-office next week. Will push when coming back.
>
>         Thanks, Richard.
>
>         -----Original Message-----
>         From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
>         <mailto:vladimir.kozlov at oracle.com>
>         Sent: Dienstag, 24. September 2019 21:04
>         To: Reingruber, Richard <richard.reingruber at sap.com>
>         <mailto:richard.reingruber at sap.com>;
>         hotspot-compiler-dev at openjdk.java.net
>         <mailto:hotspot-compiler-dev at openjdk.java.net>;
>         serviceability-dev at openjdk.java.net
>         <mailto:serviceability-dev at openjdk.java.net>
>         Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if
>         JVMTI capability can_get_owned_monitor_info was taken
>
>         I read discussion and this change looks good to me.
>
>         May be add comment that it is onload capability and can't be
>         changed during execution.
>
>         Thanks,
>         Vladimir
>
>         On 9/6/19 7: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.
>
>             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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190926/2baae944/attachment.html>