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

[Igor Veresov]

On Thu, 11 Feb 2021 17:47:54 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 refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Changes requested by iveresov (Reviewer).

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

> 514:   // This is ok because counters are unsigned by nature, and it gives us
> 515:   // another factor of 2 before the counter values become meaningless.
> 516:   // Print a "overflow" notification to create awareness.

What ```invocation_count()``` returns (which is currently equivalent to ```interpreter_invocation_count()``` btw) comes from the ```InvocationCounter::count()``` which cannot grow beyond 2^31, so all these counts are always positive. What exactly do these casts to unsigned do?

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

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