Semeru containers based on OpenJ9 release 0.33 show AOT incompatility problem

[mpirvu]

Running docker run --rm -it ibm-semeru-runtimes:open-17.0.4_8-jre java -Xjit:verbose -version on a skylake machine shows that no AOT loads are performed. Moreover, the verbose output says:

#INFO:  AOT header validation failed: Processor incompatible.

The same command works fine on a recent "cascade-lake" processor.

I looked at the dockerfile definition and it includes -XX:+PortableSharedCache, so the JIT should have generated portable AOT code capable of executing on older processors.

ENV JAVA_TOOL_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions -XX:+PortableSharedCache -XX:+IdleTuningGcOnIdle -Xshareclasses:name=openj9_system_scc,cacheDir=/opt/java/.scc,readonly,nonFatal"

[mpirvu]

Printing information about the SCC in a container with OpenJ9 0.33 we find:

Cache created with:
        -Xnolinenumbers                      = false
        BCI Enabled                          = true
        Restrict Classpaths                  = false
        Feature                              = cr
        Processor Features                   = fpu cx8 cmov mmx
                                               sse sse2 sse3 ssse3
                                               sse4_1 popcnt aesni
                                               avx avx512dq

If I try the same in a container with OpenJ9 0.32 where AOT is loading as expected we find:

Cache created with:
        -Xnolinenumbers                      = false
        BCI Enabled                          = true
        Restrict Classpaths                  = false
        Feature                              = cr
        Processor Features                   = fpu cx8 cmov mmx
                                               sse sse2 sse3 ssse3
                                               sse4_1 popcnt aesni
                                               avx

The difference is vx512dq which is added to SCC for 0.33

[mpirvu]

Running on a cascade-lake machine and creating a SCC with a recent OpenJ9 build we get these features:

        Processor Features                   = fpu cx8 cmov mmx
                                               sse sse2 sse3 ssse3
                                               fma sse4_1 popcnt
                                               aesni osxsave avx
                                               fdp_excptn_only
                                               avx512dq rdseed
                                               avx512vl null

If I add -XX:+PortableSharedCache to the command line option, I get these features:

Cache created with:
        -Xnolinenumbers                      = false
        BCI Enabled                          = true
        Restrict Classpaths                  = false
        Feature                              = cr
        Processor Features                   = fpu cx8 cmov mmx
                                               sse sse2 sse3 ssse3
                                               sse4_1 popcnt aesni
                                               avx avx512dq

I think we should have excluded avx512dq from the feature set.

[mpirvu]

PR #14258 added support for AVX512 and included this in the feature array used for J9::X86::CPU::detectRelocatable(OMRPortLibrary * const omrPortLib).
https://github.com/eclipse-openj9/openj9/blob/master/runtime/compiler/x/env/J9CPU.cpp#L41-L48
This list is supposed to include only what a Sandy-Bridge architecture supports.

[0xdaryl]

I wonder if the comment at https://github.com/eclipse-openj9/openj9/blob/master/runtime/compiler/x/env/J9CPU.cpp#L41-L48 could be made clearer to state that ONLY features supported on a SandyBridge should be included in that list. Otherwise, I can understand how a mistake could occur.

[mstoodle]

Since this issue can introduce a significant startup performance regression (one of the key value propositions for OpenJ9) and skylakes aren't that uncommon, I would support releasing this as an update on top of 0.33 (i.e. a 0.33.1) so that we can reduce the number of users affected by it. Also, the fix is very simple an unlikely to add any risk.

[mpirvu]

Issue was fixed in #15699