RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v24]

[Aleksey Shipilev]

On Fri, 22 Sep 2023 03:28:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Using `long` is to avoid build failure on 32-bit ARM and x86. `jlong` is `long long` on 32-bit, and Atomic template does not support `long long` on 32-bit. Example failure: https://github.com/jjoo172/jdk/actions/runs/6229455243/job/16907994694.
>> 
>> Is there a better way to avoid these failures on 32-bit?
>
> `long` is 32-bit on Windows x64 as well which means you're reducing the utility of these timers there (else you could use 32-bit everywhere).
> 
> AFAICS it should be supported on x86-32 as we define `SUPPORTS_NATIVE_CX8` whilst for ARM it is restricted to ARMv7a and above. (Does anyone build ARMv6 still?) But that appears not to be handled by the atomic templates.
> 
> Not sure the best way to approach this one. If the templates correctly handled SUPPORTS_NATIVE_CX8 to define the 64-bit variants then the ideal solution would be to use a typedef that is 64-bit on supported platforms and 32-bit elsewhere.

Looks to me that x86_32 actually implements PlatformCmpxchg<8> (via linux_x86.S assembly), but not PlatformAdd<8>. So maybe the workaround would be to use Atomic::cmpxchg for this update, at least on _LP64 path? I see CollectedHeap::publish_total_cpu_time already does the CAS too.

A cleaner solution would be to implement PlatformAdd<8> for x86_32, which would could be expressed via PlatformCmpxchg<8>, I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15082#discussion_r1337163806