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

[Vladimir Kozlov]

On 3/22/16 2:10 PM, Chris Plummer wrote:
> Hi Vladimir,
>
> I just noticed that there are already about 50 occurrences of:
>
> #if defined(COMPILER2) || INCLUDE_JVMCI

I know about that. I thought I can use you to fix it ;)

>
> Should I just leave my changes as-is to be consistent?

Okay, if you don't want to do that I am fine with that.

I filed RFE:
https://bugs.openjdk.java.net/browse/JDK-8152470

Thanks,
Vladimir

>
> thanks,
>
> Chris
>
> On 3/21/16 6:09 PM, Chris Plummer wrote:
>> Ok. That sounds like a good idea.
>>
>> thanks,
>>
>> Chris
>>
>> On 3/21/16 5:02 PM, Vladimir Kozlov wrote:
>>> Chris can you also replace:
>>>
>>> #if defined(COMPILER2) || INCLUDE_JVMCI
>>>
>>> with
>>>
>>> #if COMPILER2_OR_JVMCI
>>>
>>> where
>>>
>>> // COMPILER2 or JVMCI
>>> #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
>>
>