Assert failure " old api and new api did not match, feature 107"

[mpirvu]

I encountered the following assert while running on an Amazon t3.micro instance:

Assertion failed at /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-x64-openj9/workspace/build/src/build/linux-x86_64-normal-server-release/vm/compiler/../omr/compiler/x/env/OMRCPU.cpp:269: self()->supports_feature_test(feature)
Assertion failed at /home/jenkins/workspace/build-scripts/jobs/jdk8u/jdk8u-linux-x64-openj9/workspace/build/src/build/linux-x86_64-normal-server-release/vm/compiler/../omr/compiler/x/env/OMRCPU.cpp:269: self()->supports_feature_test(feature)
VMState: 0x0005ffff
        old api and new api did not match, feature 107
compiling java/lang/StringBuilder.appendCodePoint(I)Ljava/lang/StringBuilder; at level: cold

Processor info as given by lscpu:

Model name:          Intel(R) Xeon(R) Platinum 8175M CPU @ 2.50GHz
Stepping:            4
CPU MHz:             2499.998
BogoMIPS:            4999.99
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            1024K
L3 cache:            33792K
NUMA node0 CPU(s):   0,1
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke

OpenJ9 version info:

openjdk version "1.8.0_262"
OpenJDK Runtime Environment (build 1.8.0_262-202006021740-b04)
Eclipse OpenJ9 VM (build master-67cfc3512, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20200602_660 (JIT enabled, AOT enabled)
OpenJ9   - 67cfc3512
OMR      - c65b0bcaf
JCL      - 285e6577 based on jdk8u262-b04)

Attn: @harryyu1994

[DanHeidinga]

@mpirvu Is this a blocker for the 0.21.0 release? If so, please add it to the 0.21 milestone and add the blocker label

[harryyu1994]

#define OMR_FEATURE_X86_RTM 96 + 11 /* Restricted Transactional Memory */
Feature 107 is OMR_FEATURE_X86_RTM

There is only one instance in the codebase. I think I have an idea why the assertion triggered.

   TR_ASSERT_FATAL(comp->target().cpu.supportsFeature(OMR_FEATURE_X86_RTM) == _targetProcessorInfo.supportsTM(), "supportsTM() failed\n");

   if (comp->target().cpu.supportsFeature(OMR_FEATURE_X86_RTM) && !comp->getOption(TR_DisableTM))
      {
      /**
        * Due to many verions of Haswell and a small number of Broadwell have defects for TM and then disabled by Intel,
        * we will return false for any versions before Broadwell.
        *
        * TODO: Need to figure out from which mode of Broadwell start supporting TM
        */

      case OMR_FEATURE_X86_RTM:
         return TR::CodeGenerator::getX86ProcessorInfo().supportsTM() == ans;

Coming up with a fix now.

[harryyu1994]

@mpirvu is this running with JITServer? and does it happen consistently?

[harryyu1994]

Okay some explanations for the failure and I can fix this by the end of today:

My assertions are testing the newly implemented processor detection api's against the old processor detection api's. And when they are different, the assert gets triggered.

I'm guessing the assert failure will only be trigged in JITServer mode.
The old api's are using JITClient's processor information and the new api is still querying the JITServer's own processor information. Need to get this fixed.

[mpirvu]

is this running with JITServer? and does it happen consistently?

Yes, I saw it on the JITServer and it happens every single time.
It shows if the processors at the client and server are different.

[harryyu1994]

If it's convenient for you, I have the fixes here #9837 and eclipse-omr/omr#5298 that you can cherry-pick in and verify.

[mpirvu]

This should have be fixed now. I'll verify by building 0.21.0 with JITServer

[mpirvu]

I verified that the problem is fixed