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

[Igor Veresov]

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

src/hotspot/share/runtime/java.cpp line 100:

> 98: int compare_methods(Method** a, Method** b) {
> 99:   return (int32_t)(((uint32_t)(*b)->invocation_count() + (*b)->compiled_invocation_count())
> 100:                  - ((uint32_t)(*a)->invocation_count() + (*a)->compiled_invocation_count()));

Is this correct? The arithmetic look to be: (int32_t) (uint64_t - uint64_t). If the 64 values inside don't fit in 32, you'll get a negative number which would break the sorting logic.

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

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