On Fri, 22 Sep 2023 03:28:18 GMT, David Holmes <dhol...@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
