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

Chris Plummer chris.plummer at oracle.com
Tue Mar 22 01:09:00 UTC 2016

Ok. That sounds like a good idea.



On 3/21/16 5:02 PM, Vladimir Kozlov wrote:
> Chris can you also replace:
> #if defined(COMPILER2) || INCLUDE_JVMCI
> with
> where
> #if defined(COMPILER2) || INCLUDE_JVMCI
> #define COMPILER2_OR_JVMCI 1
> Thanks,
> Vladimir
> On 3/21/16 4:53 PM, Chris Plummer wrote:
>> 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