On Thu, 11 Feb 2021 17:47:54 GMT, Lutz Schmidt <l...@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
