RFR (M) 8233913: Remove implicit conversion from Method* to methodHandle

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Mon Nov 11 19:59:55 UTC 2019


Summary: Fix call sites to use existing THREAD local or pass down THREAD 
local for shallower callsites. Make linkResolver methods return Method* 
for caller to handleize if needed.

There are a small number of changes to several files, mostly obvious.  
Some comments on a few of the specific changes:

http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/aot/aotCompiledMethod.cpp.udiff.html
http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/code/nmethod.cpp.udiff.html
The comment and the methodHandle don't make sense since there'a s NSV 
there.  Method* will not be reclaimed ever, and it doesn't move.  There 
might have been a safepoint here once.

http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/ci/ciMethod.cpp.udiff.html
If you have a methodHandle, you don't need to do mh()->max_stack().   
The -> operator will expose the underlying Method*.

http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/classfile/javaClasses.cpp.udiff.html
The Method* in the vframeStream is safe here because the stack frame are 
followed in case of safepoint, and will mark the Method* as live, so 
this was unnecessary.

http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/compiler/tieredThresholdPolicy.hpp.udiff.html
I changed several of the TieredThresholdPolicy functions to take const 
methodHandle as a parameter to avoid unhandleizing and rehandleizing, 
and avoid Thread::current() calls.

http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev/src/hotspot/share/interpreter/linkResolver.hpp.udiff.html
I changed LinkResolver methods to return Method* to avoid unnecessary 
handlizing.  The handle copy is elided by most compilers but it was 
still not needed by many callers.

Tested with tier1 on all Oracle platforms, and tier 2-3 on linux-x64.

I also performance tested this with slight avg 0.5% improvement, and 
fewer instructions:

eg: PerfStartup-Noop instructions on linux-x64 (before/after)

0.49% 
<http://aurora.se.oracle.com/performance/reporting/report/details/coleen.phillimore.handles-full?type=Linux%20x64%20Server&series=Perfstartup-Noop&benchmark=perfstartup.instructions&compareTo=first>
149943356.15
± 262156.46
	149213135.00
± 281141.80
p = 0.000



open webrev at http://cr.openjdk.java.net/~coleenp/2019/8233913.01/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8233913

thanks,
Coleen









More information about the hotspot-dev mailing list