[crac] RFR: RFC: -XX:CPUFeatures=0xnumber for CPU migration [v5]

[Dan Heidinga]

On Fri, 17 Feb 2023 13:33:55 GMT, Jan Kratochvil <duke at openjdk.org> wrote:

> I hope I have addressed all the comments.
> 
> * `-XX:+ShowCPUFeatures` produces: `This machine's CPU features are: -XX:CPUFeatures=0x7fff9dfcfbf7`
> * `-XX:CPUFeatures=native`
> * `-XX:CPUFeatures=generic` - the only problem is what features should be the default, the current one is definitely wrong

One reasonable design point for `generic` is to match the set of features allowed when compiling the JVM so that a checkpoint is as portable as running the app with the java executable.  The extra trick is to then remove any features from that set that C2 doesn't use so we have the best possible portability based on what is actually required.

Given the current code for `=generic`:

    // FIXME: This is for: Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
    return 0 | CPU_CX8 | CPU_CMOV | CPU_FXSR | CPU_MMX | CPU_SSE | CPU_SSE2
      | CPU_SSE3 | CPU_SSSE3 | CPU_SSE4_1 | CPU_SSE4_2 | CPU_POPCNT | CPU_LZCNT
      | CPU_TSC | CPU_AVX | CPU_AVX2 | CPU_AES | CPU_ERMS | CPU_CLMUL
      | CPU_BMI1 | CPU_BMI2 | CPU_FMA | CPU_VZEROUPPER | CPU_FLUSH | CPU_HV;
  }

Are there any features that can be pruned from that set?  Does Hotspot actually use all of the CPU_XX capabilities?

Is Xeon a reasonable proxy for the default `make` configuration on a linux x86-64 system?  Grepping the code base I failed to turn up a good `-mtune=` or `-march=` for x86-64.

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

PR: https://git.openjdk.org/crac/pull/41