RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu May 28 16:02:58 UTC 2020


Vladimir Ivanov is on break currently.
It looks good to me.

Thanks,
Vladimir K

On 5/26/20 7:31 AM, Reingruber, Richard wrote:
> Hi Vladimir,
> 
>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
> 
>> Not an expert in JVMTI code base, so can't comment on the actual changes.
> 
>>   From JIT-compilers perspective it looks good.
> 
> I put out webrev.1 a while ago [1]:
> 
> Webrev:        http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/
> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/
> 
> You originally suggested to use a handshake to switch a thread into interpreter mode [2]. I'm using
> a direct handshake now, because I think it is the best fit.
> 
> May I ask if webrev.1 still looks good to you from JIT-compilers perspective?
> 
> Can I list you as (partial) Reviewer?
> 
> Thanks, Richard.
> 
> [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
> [2] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030340.html
> 
> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Freitag, 7. Februar 2020 09:19
> To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
> 
> 
>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
> 
> Not an expert in JVMTI code base, so can't comment on the actual changes.
> 
>   From JIT-compilers perspective it looks good.
> 
> Best regards,
> Vladimir Ivanov
> 
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8238585
>>
>> The change avoids making all compiled methods on stack not_entrant when switching a java thread to
>> interpreter only execution for jvmti purposes. It is sufficient to deoptimize the compiled frames on stack.
>>
>> Additionally a handshake is used instead of a vm operation to walk the stack and do the deoptimizations.
>>
>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on all platforms.
>>
>> Thanks, Richard.
>>
>> See also my question if anyone knows a reason for making the compiled methods not_entrant:
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html
>>


More information about the hotspot-gc-dev mailing list