MethodInvocationCounters frequently run into overflow

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.