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

Reingruber, Richard richard.reingruber at sap.com
Mon Sep 9 09:43:14 UTC 2019


Hi Serguei, Dean,

  > This looks good to me.

Thanks for reviewing the change, Serguei.

  > One question though.
  > Suppose some methods got compiled/optimized with the escape analysis.
  > Then nothing prevents to enable the JVMTI capabilities later and use the
  > JVMTI functions GetOwnedMonitorInfo()and GetOwnedMonitorStackDepthInfo().
  > 
  > Should enabling the capabilities cause deoptimization
  > of the already optimized compiled frames?

Dean is right can_get_owned_monitor_info and can_get_owned_monitor_stack_depth_info are onload capabilities:

see JvmtiManageCapabilities::init_onload_capabilities()
http://hg.openjdk.java.net/jdk/jdk/file/8009a9c36251/src/hotspot/share/prims/jvmtiManageCapabilities.cpp#l127

So they cannot be enabled later.

Good question anyway, because can_tag_objects is an always capability and has the same issues with
escape analysis.

  > Is this considered to be a part of the JDK-8227745?

Yes, but with JDK-8227745 there's no need to disable escape analysis.

Thanks, Richard.

-----Original Message-----
From: hotspot-compiler-dev <hotspot-compiler-dev-bounces at openjdk.java.net> On Behalf Of dean.long at oracle.com
Sent: Samstag, 7. September 2019 10:20
To: hotspot-compiler-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 had the same concern, and I think it's OK if these capabilities can 
only be enabled during OnLoad.

dl

On 9/6/19 6:08 PM, serguei.spitsyn at oracle.com wrote:
> Hi Richard,
>
> This looks good to me.
> One question though.
>
> Suppose some methods got compiled/optimized with the escape analysis.
> Then nothing prevents to enable the JVMTI capabilities later and use the
> JVMTI functions GetOwnedMonitorInfo()and GetOwnedMonitorStackDepthInfo().
>
> Should enabling the capabilities cause deoptimization
> of the already optimized compiled frames?
> Is this considered to be a part of the JDK-8227745?
>
> Thanks,
> Serguei
>
>
> 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
>



More information about the hotspot-compiler-dev mailing list