[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
Hello,
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).
http://cr.openjdk.java.net/~cjplummer/8148639/webrev.03/webrev.hotspot/
https://bugs.openjdk.java.net/browse/JDK-8148639
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).
thanks,
Chris
More information about the hotspot-compiler-dev
mailing list