-
Bug
-
Resolution: Fixed
-
P4
-
11, 17
-
b13
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8265365 | 11.0.12 | Lucy Schmidt | P4 | Resolved | Fixed | b01 |
The design of method invocation counters dates back many years. Back then, the range of a signed int seemed by far sufficient to count the invocations of all methods. In the meantime, single-core speed has increased dramatically, as has the number of cores per (virtual) system. This gain in processing power leads to quick overflow of 32bit counters. Even trivial tests, like a JVM98 run with -XX:+CountCompiledCalls, show the effect:
Invocations summary:
4312091 ( 0.1%) interpreted
-186276831 (99.9%) compiled
-181964740 (100%) total
614123904 (14.9%) synchronized
534657511 (13.0%) final
191605878 ( 4.7%) static
13486 ( 0.0%) native
23943 ( 0.0%) accessor
The printed counter summary is useless. More can be found in the attached text files.
Invocation counters should be widened to 64 bit. Where that is not possible, the counters should at least be interpreted as unsigned, providing an additional factor of two before overflow (or in the unsigned case wraparound) occurs.
Invocations summary:
4312091 ( 0.1%) interpreted
-186276831 (99.9%) compiled
-181964740 (100%) total
614123904 (14.9%) synchronized
534657511 (13.0%) final
191605878 ( 4.7%) static
13486 ( 0.0%) native
23943 ( 0.0%) accessor
The printed counter summary is useless. More can be found in the attached text files.
Invocation counters should be widened to 64 bit. Where that is not possible, the counters should at least be interpreted as unsigned, providing an additional factor of two before overflow (or in the unsigned case wraparound) occurs.
- backported by
-
JDK-8265365 MethodInvocationCounters frequently run into overflow
- Resolved