RFR: 8261447: MethodInvocationCounters frequently run into overflow [v8]

[Vladimir Kozlov]

On Thu, 25 Feb 2021 09:01:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> Dear community,
>> may I please request reviews for this fix, improving the usefulness of method invocation counters.
>> - aggregation counters are retyped as uint64_t, shifting the overflow probability way out (> 500 years in case of a 1 GHz counter update frequency).
>> - counters for individual methods are interpreted as (unsigned int), in contrast to their declaration as int. This gives us a factor of two before the counters overflow.
>> - as a special case, "compiled_invocation_counter" is retyped as long, because it has a higher update frequency than other counters.
>> - before/after sample output is attached to the bug description. 
>> 
>> Thank you!
>> Lutz
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment changes requested by TheRealMDoerr

I have few comments.

src/hotspot/cpu/x86/vtableStubs_x86_32.cpp line 159:

> 157:     return NULL;
> 158:   }
> 159: 

Why you did not update asm instruction to update `nof_megamorphic_calls` in this file?

src/hotspot/share/oops/method.cpp line 530:

> 528: 
> 529:   if (method_data() != NULL) {
> 530:     unsigned int dcc    = (unsigned int)method_data()->decompile_count();

decompile_count() returns `uint` why do cast and why you check decompile_count for overflow? It is very rare updated and limited by `PerMethodRecompilationCutoff` flag (400 by default):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/oops/methodData.hpp#L2391

src/hotspot/share/oops/method.cpp line 518:

> 516:   // Print a "overflow" notification to create awareness.
> 517:   const char* addMsg;
> 518:   unsigned int maxInt = (1U<<31) - 1;

Why not use INT_MAX?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2511