Description of problem: hsdis-amd64.so could not be found on RHEL. Due to which The Java Hotspot compiler seem to generate not optimal machine specific code for that CPU family. # java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 7.2 java-1.8.0-openjdk-1.8.0.77-0.b03.el7_2.x86_64 How reproducible: Always Steps to Reproduce: 1. # java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly Actual results: # java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled Expected results: Print the assembly code. # java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly OpenJDK 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output Loaded disassembler from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.77-0.b03.el7_2.x86_64/jre/lib/amd64/server/hsdis-amd64.so Decoding compiled method 0x00007fefc5107d50: Code: [Disassembling for mach='i386:x86-64'] [Entry Point] # {method} {0x00007fefd8d94738} 'arraycopy' '(Ljava/lang/Object;ILjava/lang/Object;II)V' in 'java/lang/System' # parm0: rsi:rsi = 'java/lang/Object' # parm1: rdx = int # parm2: rcx:rcx = 'java/lang/Object' # parm3: r8 = int # parm4: r9 = int # [sp+0x60] (sp of caller) 0x00007fefc5107ec0: mov 0x8(%rsi),%r10d 0x00007fefc5107ec4: shl $0x3,%r10 0x00007fefc5107ec8: cmp %r10,%rax 0x00007fefc5107ecb: je 0x000 Additional info: We have observed Java application performance slowdown on newest HP Z640 workstation with Intel(R) Xeon(R) CPU E5-1650 v3. So, trying to understand the performance drop of the Java DREM instruction on latest Xeon CPU installed on HP Z640 workstation. Also tried compiling the library from source, but fails. cd /data/rpmbuild/BUILD/java-1.8.0-openjdk-1.8.0.77-0.b03.el7.x86_64/openjdk/hotspot/src/share/tools/hsdis BINUTILS=/home/user/git/binutils-gdb/binutils make all64 ... lot of output ... if [ ! -f build/linux-amd64/bfd/libbfd.a ]; then cd build/linux-amd64; make all-opcodes; fi make[2]: Entering directory `/data/rpmbuild/BUILD/java-1.8.0-openjdk-1.8.0.77-0.b03.el7.x86_64/openjdk/hotspot/src/share/tools/hsdis/build/linux-amd64' make[2]: *** No rule to make target `all-opcodes'. Stop. make[2]: Leaving directory `/data/rpmbuild/BUILD/java-1.8.0-openjdk-1.8.0.77-0.b03.el7.x86_64/openjdk/hotspot/src/share/tools/hsdis/build/linux-amd64' make[1]: *** [build/linux-amd64/bfd/libbfd.a] Error 2 make[1]: Leaving directory `/data/rpmbuild/BUILD/java-1.8.0-openjdk-1.8.0.77-0.b03.el7.x86_64/openjdk/hotspot/src/share/tools/hsdis' make: *** [all64] Error 2
I've originally reported this bug via RH case 01614360 and would like to correct the problem statement: the absence of the hsdis-amd64.so on RHEL does *not* cause the JIT compiler to generate slower or different code! The problem is that *without* hsdis-amd64.so library we are unable to force JIT compiler / JVM to print generated assembly via "-XX:+PrintAssembly" flag. Not only the hsdis-amd64.so library is not available as rpm for RHEL, it also *cannot be build* from OpenJDK sources distributed by RH. So if the library cannot be distributed by RH due some limitations or license issues, it should be at least possible to build it from openjdk/hotspot/src/share/tools/hsdis sources. And this is currently failing with the error: if [ ! -f build/linux-amd64/bfd/libbfd.a ]; then cd build/linux-amd64; make all-opcodes; fi make[2]: Entering directory `/data/rpmbuild/BUILD/java-1.8.0-openjdk-1.8.0.77-0.b03.el7.x86_64/openjdk/hotspot/src/share/tools/hsdis/build/linux-amd64' make[2]: *** No rule to make target `all-opcodes'. Stop. Looking at the makefile in linux-amd64, the "all-opcodes" target is obviously missing. So either this makefile or the parent one which tries to trigger it were not properly merged or some of the changes from upstream are missing.
The hsdis plugin isn't built as part of OpenJDK and requires a binutils source tree to be compiled. The result is not distributable, as it will combine GPLv2 (HotSpot) and GPLv3 (binutils code). I'm not seeing the error you're getting locally. How are you trying to build it? $ make -C src/share/tools/hsdis all64 make: Entering directory '/home/andrew/projects/openjdk/upstream/chailatte-u60/hotspot/src/share/tools/hsdis' LIBARCH = i386 make LP64=1 all make[1]: Entering directory '/home/andrew/projects/openjdk/upstream/chailatte-u60/hotspot/src/share/tools/hsdis' LIBARCH = amd64 [ -d build/linux-amd64 ] || mkdir -p build/linux-amd64 /bin/sh: line 0: cd: build/binutils: No such file or directory (cd build/linux-amd64; CC=gcc CFLAGS="-m64 -fPIC -g -O0" AR="ar" /home/andrew/projects/openjdk/upstream/chailatte-u60/hotspot/src/share/tools/hsdis/configure --disable-nls ) /bin/sh: /home/andrew/projects/openjdk/upstream/chailatte-u60/hotspot/src/share/tools/hsdis/configure: No such file or directory Makefile:204: recipe for target 'build/linux-amd64/Makefile' failed The failure here is because I haven't pointed it at a binutils tree to build.
FYI there is information about PrintAssembly and the plugin here: https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly
(In reply to Andrew John Hughes from comment #3) > FYI there is information about PrintAssembly and the plugin here: > https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly I know. There were two reasons for me for compilaton from sources: 1. There were few sources in internet describing crashes of the plugin used together with OpenJDK. 2. Trust. I have no idea who and how compiled that so file and so using this in our R&D lab is not really acceptable. So I've cloned binutils, tried to build from the head but failed. So I've checked out some older tag (corresponding one of the "known good" versions mentioned in the readme) and the build of binutils part went through but stopped at missing all-opcodes target in hsdis. Check the main hsdis Makefile, you will see that this all-opcodes is called but for whatever reason there is no such target in the other hsdis makefiles. So I guess they were diverged over time. Unfortunately I have not the source tree with history for that (rpm contained only the snapshot) so I can't say if the problem is in RH OpenJDK specific patches or in the upstream code.
(In reply to Andrey Loskutov from comment #4) > (In reply to Andrew John Hughes from comment #3) > > FYI there is information about PrintAssembly and the plugin here: > > https://wiki.openjdk.java.net/display/HotSpot/PrintAssembly > > I know. There were two reasons for me for compilaton from sources: > 1. There were few sources in internet describing crashes of the plugin used > together with OpenJDK. > 2. Trust. I have no idea who and how compiled that so file and so using this > in our R&D lab is not really acceptable. > I wasn't suggesting that page for a binary (ugh) but information about the plugin. That's all. > So I've cloned binutils, tried to build from the head but failed. So I've > checked out some older tag (corresponding one of the "known good" versions > mentioned in the readme) and the build of binutils part went through but > stopped at missing all-opcodes target in hsdis. Check the main hsdis > Makefile, you will see that this all-opcodes is called but for whatever > reason there is no such target in the other hsdis makefiles. So I guess they > were diverged over time. Unfortunately I have not the source tree with > history for that (rpm contained only the snapshot) so I can't say if the > problem is in RH OpenJDK specific patches or in the upstream code. There aren't really any RH patches for 8, at least not in this area. I'll have a look myself, but it'll have to wait until the current security update is out of the way.
The hsdis license was updated upstream: http://hg.openjdk.java.net/jdk/jdk/rev/59b0d8afc831 I don't know if this solves the licensing problem, considering that it's for use with Hotspot, which is GPLv2-only.
The license has changed, but while it still requires binutils to be linked against HotSpot (not just the plugin), I tend to concur with aph that there's still an issue: https://mail.openjdk.java.net/pipermail/build-dev/2018-August/022906.html (though neither of us are lawyers, so this does not constitute legal advice) If it does get ported to Capstone, then I guess it becomes more of an issue of getting Capstone packaged in RHEL.
Red Hat Enterprise Linux 7 shipped it's final minor release on September 29th, 2020. 7.9 was the last minor releases scheduled for RHEL 7. From intial triage it does not appear the remaining Bugzillas meet the inclusion criteria for Maintenance Phase 2 and will now be closed. From the RHEL life cycle page: https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase "During Maintenance Support 2 Phase for Red Hat Enterprise Linux version 7,Red Hat defined Critical and Important impact Security Advisories (RHSAs) and selected (at Red Hat discretion) Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available." If this BZ was closed in error and meets the above criteria please re-open it flag for 7.9.z, provide suitable business and technical justifications, and follow the process for Accelerated Fixes: https://source.redhat.com/groups/public/pnt-cxno/pnt_customer_experience_and_operations_wiki/support_delivery_accelerated_fix_release_handbook Feature Requests can re-opened and moved to RHEL 8 if the desired functionality is not already present in the product. Please reach out to the applicable Product Experience Engineer[0] if you have any questions or concerns. [0] https://bugzilla.redhat.com/page.cgi?id=agile_component_mapping.html&product=Red+Hat+Enterprise+Linux+7
There is now active upstream work on a port to LLVM, motivated by the MacOS + AArch64 port. This may be a better choice for use in RHEL, as LLVM is already available.
*** Bug 1897563 has been marked as a duplicate of this bug. ***
See also https://github.com/adoptium/adoptium/issues/213