We should be able to tell from a Javacore what processor features were used for AOT compilations.
This refers to the following data as shown by -Xshareclasses:printstats
Processor Features = fpu cx8 cmov mmx sse
sse2 ssse3 fma sse4_1
popcnt aesni osxsave
avx
I've added this to the next milestone, but if there isn't time it can be pushed forward. Although it should be an easy change.
Although it should be an easy change.
Well except for the formatting which is hard coded into printAOTHeaderProcessorFeatures() and specific to the shared classes printstats output.
We should factor out the stringification of processor features out to the port library where it belongs, alongside CPU detection.
Actually this may not be as straightforward as I thought. So this could be easily done with a port library API but that will just give us the underlying processor's cpu features. The actual set of CPU features used by the compiler is later adjusted by the jit and stored in the TR::CPU class. I failed to see how we can get access to that information from the javadump.cpp (I'm assuming this is where it needs to go). Any suggestions?
I guess the way to access jit information is through vmThread->javaVM->jitConfig
I guess the way to access jit information is through
vmThread->javaVM->jitConfig
This is the correct way, however make sure to check if this is present, because the VM may not have loaded the JIT library (for example -Xint). The port library API should still be the one determining the string, given an OMRProcessorDesc.
fyi perhaps obvious, from the shared classes perspective the java dump uses the getJavacoreData api.
https://github.com/eclipse/openj9/blob/master/runtime/rasdump/javadump.cpp#L3273
https://github.com/eclipse/openj9/blob/master/runtime/shared_common/shrinit.cpp#L1747
Does this format look okay?
1CICPUINFO CPU Information
NULL ------------------------------------------------------------------------
2CIPHYSCPU Physical CPUs: 8
2CIONLNCPU Online CPUs: 8
2CIBOUNDCPU Bound CPUs: 8
2CIACTIVECPU Active CPUs: 0
2CITARGETCPU Target CPUs: 8
2CIJITFEATURE CPU features (JIT): fpu cx8 cmov mmx
sse sse2 ssse3 fma
sse4_1 popcnt aesni
osxsave avx avx2
rdt_m
2CIAOTFEATURE CPU features (AOT): fpu cx8 cmov mmx
sse sse2 ssse3 fma
sse4_1 popcnt aesni
osxsave avx avx2
rdt_m
Corresponding OMR change: https://github.com/eclipse/omr/pull/5675
Does this format look okay?
No, each line needs to have a code. It could look like this.
2CIJITFEATURE CPU features (JIT): fpu cx8 cmov mmx
3CIJITFEATURE sse sse2 ssse3 fma
3CIJITFEATURE sse4_1 popcnt aesni
3CIJITFEATURE osxsave avx avx2
3CIJITFEATURE rdt_m
Just list them all on one line the same way /proc/cpuinfo does IMO.
1CICPUINFO CPU Information
NULL ------------------------------------------------------------------------
2CIPHYSCPU Physical CPUs: 8
2CIONLNCPU Online CPUs: 8
2CIBOUNDCPU Bound CPUs: 8
2CIACTIVECPU Active CPUs: 0
2CITARGETCPU Target CPUs: 8
2CIJITFEATURE CPU features (JIT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m
2CIAOTFEATURE CPU features (AOT): fpu cx8 cmov mmx sse sse2 ssse3 fma sse4_1 popcnt aesni osxsave avx avx2 rdt_m
1CICPUINFO CPU Information
NULL ------------------------------------------------------------------------
2CIPHYSCPU Physical CPUs: 8
2CIONLNCPU Online CPUs: 8
2CIBOUNDCPU Bound CPUs: 8
2CIACTIVECPU Active CPUs: 0
2CITARGETCPU Target CPUs: 8
2CIINTFEATURE CPU features (INT): fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clfsh mmx fxsr sse sse2 ss sse3 pclmulqdq vmx ssse3 fma cmpxchg16b pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline aesni xsave osxsave avx f16c rdrand null ia32_tsc_adjust hle avx2 fdp_excptn_only bmi2 ermsb invpcid rtm rdt_m adx smap avx512_ifma
@harryyu1994 is the PR likely to be ready in the next week? We split for the 0.24 release next weekend.
@harryyu1994 is the PR likely to be ready in the next week? We split for the 0.24 release next weekend.
I think it's already done, I just haven't tested the latest change yet. Will do it tomorrow.
@harryyu1994 I assume this is fixed via #11388 (after it was reverted and re-added), and this can be closed now? Note you can use auto-close keywords in your PRs. i.e. closes #11184 or fixes #11184 instead of issue #11184.
What I like to do is put Issue into the commit comment, but change this to Fixes or Closes when creating the PR.
Actually, in order to get these changes into the 0.24.0 release, please open PRs for the OMR and OpenJ9 changes against the v0.24.0-release branches.
This looks like it should have had a docs:externals label so that we could update https://eclipse.github.io/openj9-docs/dump_javadump/#gpinfo.
@harryyu1994 @pshipton
@SueChaplain yes sorry, added the label. Do you need any sample output provided?
Most helpful comment