[9] RFR (S) 8148639: Some MethodCounter fields can be excluded when not including C2

Chris Plummer chris.plummer at oracle.com
Mon Mar 21 23:53:28 UTC 2016


Please review the following for removing a couple of MethodCounter 
fields when not including C2 (or JVMCI) in the build. This helps reduce 
footprint for the minimal VM (and the client VM also).


There were a couple of changes the previously were in JDK-8147978 that I 
had to add to this webrev since JDK-8147978 was backed out. They include 
making ProfileInterpreter related options unsupported when not using C2, 
and also the new macros in macros.hpp.

In order to make sure these counters really are not used when not using 
C2, I took a few safeguards. The first was to make no changes other than 
to assert that whenever these counters are fetched, they are equal to 
zero. I did quite a bit of testing with this and never hit the asserts.

I would have liked to #ifdef out interpreter_invocation_count() and 
interpreter_throwout_count(), but there are too many places that call 
them, which meant too many #ifdef in IMHO. So instead of #ifdef'ing them 
out, I just make them return 0 when not using C2. This is safe because 
of the assert testing I did above.

I do completely #ifdef out the two increment methods. 
interpreter_throwout_increment() is only called by some 
ProfileInterpreter code in bytecodeInterpreter.cpp, so I #ifdef'd that 
code also. In interpreterRuntime.cpp I #ifdef'd out a call to 
interpreter_throwout_increment(). Although this code may have been 
executed when not using C2, the assert testing I did above showed that 
if the increment happened, the counter was never used later.

There are quite a few #ifdefs in methodCounters.hpp. I could collpase 5 
into one big #if/#else/#endif section for all the inline method 
implementations. It looks cleaner, be then also puts distance between 
the two different versions of the same method.

Testing was done with jprt "-testset hotspot". I also did a lot of 
testing with various tools, svc, and compiler test lists, and also 
runThese. This was done on linux-x86 with "-client -Xcomp" and just 
"-client", and also on linux-x64 with "-server -XX:+TieredCompilation" 
(although I think that was probably the default anyway).



More information about the hotspot-compiler-dev mailing list