> 393: * The returned allocator might throw an {@link OutOfMemoryError} if the total memory allocated with this allocator > 394: * exceeds the arena size, or the system capacity. Furthermore, the returned allocator is not thread safe, and all The "the returned allocator is not thread safe" contradicts the prior sentence "An allocator associated with a shared resource scope is thread-safe and allocation requests may be performed concurrently". Perhaps just say: "

The returned allocator is not thread safe if the given scope is a shared scope. Concurrent allocation needs to be guarded with synchronization primitives. " src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 260: > 258: > 259: @Override > 260: public final MemorySegment asOverlappingSlice(MemorySegment other) { Please ignore these comments if you wish. Adding `max() // exclusive` to complement `min()` might be useful. In these cases i find it easier to sort the segments e.g. `var a = this; var b = other; if (a.min() > b.min()) { // swap a and b }` then the subsequent logic tends to get simpler e.g. overlap test is `if (b.min() < a.max())`, `segmentOffset` is always +ve. src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java line 100: > 98: do { > 99: value = (int)ASYNC_RELEASE_COUNT.getVolatile(this); > 100: } while (!ASYNC_RELEASE_COUNT.compareAndSet(this, value, value + 1)); Use `getAndAdd` (and ignore the return value). ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From ihse at openjdk.java.net Wed Oct 13 00:11:01 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 13 Oct 2021 00:11:01 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis Message-ID: This patch expands the newly added system for hsdis backends to include LLVM. The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. ------------- Commit messages: - Create hsdis backend using LLVM Changes: https://git.openjdk.java.net/jdk/pull/5920/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5920&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253757 Stats: 406 lines in 6 files changed: 398 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/5920.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5920/head:pull/5920 PR: https://git.openjdk.java.net/jdk/pull/5920 From jvernee at openjdk.java.net Wed Oct 13 00:34:48 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 13 Oct 2021 00:34:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: <-kktvlQWjVyTNwWTiTCVyW3WA1xiM5P6dcWp96WkD7k=.fc41674b-e558-4718-b820-3c60161eccc6@github.com> On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > but it caused hotspot to segfault in LoadLibrary (!) in os::dll_load when I tried to load the library. I tried compiling the binutils-based hsdis earlier as well, but on WSL instead of cygwin (using the `mingw-w64` package), and ran into the same issue. It kept segfaulting when loading the library. My guess was that it is a problem caused by mixing libraries that are compiled with different toolchains, as the JDK itself is compiled with MSVC. AFAIK binutils can only be built with mingw (based on my earlier experiments), but LLVM can be built with MSVC as well, so maybe the regular MSVC toolchain could be used to build the llvm-based hsdis. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From duke at openjdk.java.net Wed Oct 13 07:18:52 2021 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Wed, 13 Oct 2021 07:18:52 GMT Subject: RFR: 8274851: [PPC64] Port zgc to linux on ppc64le [v3] In-Reply-To: References:

Message-ID: On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote: >> Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. > > Niklas Radomski has updated the pull request incrementally with three additional commits since the last revision: > > - Remove superfluous copyright change > - Fix predicate conditions > - Add ByteSize constructor to Address The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout 8275049_ZGC_log_register git fetch https://git.openjdk.java.net/jdk master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From luhenry at openjdk.java.net Wed Oct 13 07:29:52 2021 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Wed, 13 Oct 2021 07:29:52 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. Very happy to see it landing :) Thank you! I don't have access to a windows machine, and even less a Windows-AArch64 machine. @lewurm would you be able to take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From nradomski at openjdk.java.net Wed Oct 13 07:40:57 2021 From: nradomski at openjdk.java.net (Niklas Radomski) Date: Wed, 13 Oct 2021 07:40:57 GMT Subject: Integrated: 8274851: [PPC64] Port zgc to linux on ppc64le In-Reply-To: References: Message-ID: On Wed, 6 Oct 2021 19:27:26 GMT, Niklas Radomski wrote: > Port the Z garbage collector ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux on ppc64le. This pull request has now been integrated. Changeset: 337b73a4 Author: Niklas Radomski Committer: Martin Doerr URL: https://git.openjdk.java.net/jdk/commit/337b73a459ba24aa529b7b097617434be1d0030e Stats: 1273 lines in 11 files changed: 1265 ins; 0 del; 8 mod 8274851: [PPC64] Port zgc to linux on ppc64le Reviewed-by: ihse, pliden, mdoerr, eosterlund ------------- PR: https://git.openjdk.java.net/jdk/pull/5842 From mcimadamore at openjdk.java.net Wed Oct 13 12:07:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:07:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/23f69054..d6bf27ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Wed Oct 13 12:48:06 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 13 Oct 2021 12:48:06 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/d6bf27ff..27e71ee7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=02-03 Stats: 35 lines in 4 files changed: 8 ins; 11 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From ihse at openjdk.java.net Wed Oct 13 12:55:53 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 13 Oct 2021 12:55:53 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: <-kktvlQWjVyTNwWTiTCVyW3WA1xiM5P6dcWp96WkD7k=.fc41674b-e558-4718-b820-3c60161eccc6@github.com> References: <-kktvlQWjVyTNwWTiTCVyW3WA1xiM5P6dcWp96WkD7k=.fc41674b-e558-4718-b820-3c60161eccc6@github.com> Message-ID: On Wed, 13 Oct 2021 00:32:03 GMT, Jorn Vernee wrote: >> This patch expands the newly added system for hsdis backends to include LLVM. >> >> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) >> >> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. >> >> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. > >> but it caused hotspot to segfault in LoadLibrary (!) in os::dll_load when I tried to load the library. > > I tried compiling the binutils-based hsdis earlier as well, but on WSL instead of cygwin (using the `mingw-w64` package), and ran into the same issue. It kept segfaulting when loading the library. > > My guess was that it is a problem caused by mixing libraries that are compiled with different toolchains, as the JDK itself is compiled with MSVC. > > AFAIK binutils can only be built with mingw (based on my earlier experiments), but LLVM can be built with MSVC as well, so maybe the regular MSVC toolchain could be used to build the llvm-based hsdis. @JornVernee It is likely that the LLVM-based backend can be build by MSVC, yes. I did not explore that further in this patch. I suggest that the way forward is to get this patch into mainline, and then experiment with how to get Windows support working properly. (The main problem with the MSVS approach is that the LLVM libraries, as returned by llvm-config, is in gcc format (`-lLLFoobarnicator`) which we can't send to CL. (It seems Ludovic tried to work around this by transforming the command line in his original PR.) ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From erikj at openjdk.java.net Wed Oct 13 13:02:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 13 Oct 2021 13:02:52 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: <6qvBXCAckRpSbjiyxx-6sBqrnNbe40Jzk1k7M5rV3Mk=.5daf2183-97c6-40c3-ac25-d7232153c0ad@github.com> On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From jvernee at openjdk.java.net Wed Oct 13 13:10:51 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 13 Oct 2021 13:10:51 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: <0iaKIK8JsgkNsRkAqcIoJzxGJiMiHRQfN8kGIvOWOUg=.b07bcb04-f8ce-44af-8e45-f161aea805ba@github.com> On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. In my experience the output of llvm-config is also not usable. I think the output also depends on the toolchain you use to build llvm FWIW. The output of my locally built llvm-config does contain the MSVC flags, but the paths it points to are incorrect (all pointing to the build directory, instead of the package install location). I have a patch here that gets me a working hsdis based on the llvm package I built manually using MSVC (the [official package](https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/LLVM-13.0.0-win64.exe) doesn't seem to contain the needed header files): https://github.com/openjdk/jdk/compare/pr/5920...JornVernee:hsdis_llvm_windows (The only issue currently is that the code I used to filter out the incorrect `-I` flags from what llvm-config gives me doesn't seem to work, though the build still passes). I built llvm using something like this (according to my notes): git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir build_llvm cd build_llvm cmake ../llvm -D"LLVM_TARGETS_TO_BUILD:STRING=X86" -D"CMAKE_BUILD_TYPE:STRING=Release" -D"CMAKE_INSTALL_PREFIX=install_local" -A x64 -T host=x64 cmake --build . --config Release --target install This then uses MSVC to build me an llvm 'package' in `build_llvm/install_local`, which I then point to using `--with-llvm`. The only other issue I had is that `install-hsdis` only copies the library to the exploded JDK, so I manually copy it to `images/jdk/bin/server` afterwards. HTH ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From aph at openjdk.java.net Wed Oct 13 13:57:53 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 13 Oct 2021 13:57:53 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR #392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. What is it for, then? hsdis builds on AArch64-MacOS-LLVM with cd src/utils/hsdis mkdir build cd build git clone https://github.com/bminor/binutils-gdb ln -s binutils-gdb binutils cd .. make ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From ihse at openjdk.java.net Wed Oct 13 15:08:48 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 13 Oct 2021 15:08:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: On Wed, 13 Oct 2021 13:55:04 GMT, Andrew Haley wrote: >> This patch expands the newly added system for hsdis backends to include LLVM. >> >> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) >> >> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. >> >> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. > >> This patch expands the newly added system for hsdis backends to include LLVM. >> >> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR #392. (I have basically just ripped out the binutils-based part of it.) >> >> Unfortunately I have not been able to make this work properly on Windows. > > What is it for, then? > > hsdis builds on AArch64-MacOS-LLVM with > > > cd src/utils/hsdis > mkdir build > cd build > git clone https://github.com/bminor/binutils-gdb > ln -s binutils-gdb binutils > cd .. > make @theRealAph As you might be aware, the licensing criteria for binutils makes it impossible to distribute a binutils-based hsdis with the JDK. While IANAL, my understanding is that the LLVM license is less problematic in that way. Also, this is to allow a bit of freedom of choice. If you prefer the LLVM backend (I've been told that it generates better disassembly in some case) you should be able to select it. And finally, I do think that the LLVM backend should be able to work on Windows, too. It's just that this is tricky enough to motivate doing this in a separate, later, step. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From ihse at openjdk.java.net Wed Oct 13 15:14:47 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 13 Oct 2021 15:14:47 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: <0iaKIK8JsgkNsRkAqcIoJzxGJiMiHRQfN8kGIvOWOUg=.b07bcb04-f8ce-44af-8e45-f161aea805ba@github.com> References: <0iaKIK8JsgkNsRkAqcIoJzxGJiMiHRQfN8kGIvOWOUg=.b07bcb04-f8ce-44af-8e45-f161aea805ba@github.com> Message-ID: <2eRpiyPVuQyVLhnC_05bhGbYDEgT4ezSe7--epnSYp0=.6dbb0804-4297-449f-9004-cd17dcb7e7ba@github.com> On Wed, 13 Oct 2021 13:04:45 GMT, Jorn Vernee wrote: > The only other issue I had is that `install-hsdis` only copies the library to the exploded JDK, so I manually copy it to `images/jdk/bin/server` afterwards. @JornVernee Ah, good point! I need to make sure it gets copied to the image as well. And thank you for your patch, I'll have a look at it and see if I can incorporate it in this patch, or if it's better to make it a separate patch. It's worth noting that I used the llvm package from cygwin, neither the "official" package nor a self-built. I can imagine that the self-built works better, so it might be worth adding a --with-llvm-src option to help build it as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From luhenry at openjdk.java.net Wed Oct 13 15:41:59 2021 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Wed, 13 Oct 2021 15:41:59 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. Marked as reviewed by luhenry (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From aph at openjdk.java.net Wed Oct 13 15:58:47 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 13 Oct 2021 15:58:47 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

<618eb555-c987-6f25-ab8c-2143900d6c5c@oracle.com> Message-ID: Thank you both for the responses! I am now using the https://github.com/openjdk/jdk11u-dev/ tree that you linked and I have trimmed down my cxxflags and cflags to just -O2 and -pipe, and added --with-debug-level=fastdebug. I've tried with zero build, which still works, but server, client still crash immediately, but now they also give me an assert internal error: Server: # # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_arm.hpp:240 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/johnc/Documents/openjdk/jdk11u-dev/src/hotspot/cpu/arm/assembler_arm.hpp:240), pid=1467, tid=1468 # assert(_disp == 0 && (_shift_imm >> 5) == 0) failed: encoding constraint # # JRE version: (11.0.14) (fastdebug build ) # Java VM: OpenJDK Server VM (fastdebug 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode, serial gc, linux-) # Core dump will be written. Default location: /usr/lib/jvm/jdk11/server/jdk/bin/core # Client: # # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/assembler_arm.hpp:240 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/johnc/Documents/openjdk/jdk11u-dev/src/hotspot/cpu/arm/assembler_arm.hpp:240), pid=1296, tid=1297 # assert(_disp == 0 && (_shift_imm >> 5) == 0) failed: encoding constraint # # JRE version: (11.0.14) (fastdebug build ) # Java VM: OpenJDK Client VM (fastdebug 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode, serial gc, linux-) # Core dump will be written. Default location: /usr/lib/jvm/jdk11/client/jre/bin/core # And if it helps, here's the output of -Xlog:all on the client fastdebug build # ./java -Xlog:all [0.012s][info][os] Use of CLOCK_MONOTONIC is supported [0.012s][info][os] Use of pthread_condattr_setclock is supported [0.012s][info][os] Relative timed-wait using pthread_cond_timedwait is associated with CLOCK_MONOTONIC [0.012s][info][os] HotSpot is running with glibc 2.18, NPTL 2.18 [0.013s][info][os] SafePoint Polling address: 0xb6f03000 [0.016s][info][biasedlocking] Aligned thread 0xb5f17160 to 0xb5f17400 [0.016s][info][os,thread ] Thread attached (tid: 1484, pthread id: 3054040160). [0.018s][info][os ] attempting shared library load of /usr/lib/jvm/jdk11/client/jdk/lib/libzip.so [0.019s][info][os ] shared library load of /usr/lib/jvm/jdk11/client/jdk/lib/libzip.so was successful [0.020s][info][class,path ] bootstrap loader class path=/usr/lib/jvm/jdk11/client/jdk/lib/modules [0.020s][info][class,path ] opened: /usr/lib/jvm/jdk11/client/jdk/lib/modules [0.020s][info][class,load ] opened: /usr/lib/jvm/jdk11/client/jdk/lib/modules [0.020s][info][pagesize ] CodeCache: min=160K max=32M base=0xb3d5f000 page_size=4K size=32M [0.022s][info][os,cpu ] CPU:total 2 (initial active 2) (ARMv7), vfp [0.022s][info][os,cpu ] /proc/cpuinfo: [0.022s][info][os,cpu ] Processor : ARMv7 Processor rev 4 (v7l) processor : 0 BogoMIPS : 1810.43 processor : 1 BogoMIPS : 1823.53 Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc07 CPU revision : 4 Hardware : sun7i Revision : 0000 Serial : 07c1120f5552484880758685165166cb [0.022s][info][os,cpu ] Online cpus: [0.022s][info][os,cpu ] 0-1 [0.022s][info][os,cpu ] Offline cpus: [0.023s][info][os,cpu ] [0.024s][info][startuptime ] StubRoutines generation 1, 0.0007363 secs [0.025s][info][pagesize ] Heap: min=6M max=200M base=0xa7400000 page_size=2M size=200M [0.025s][info][pagesize ] Card Table: min=409601B max=409601B base=0xb3c7a000 page_size=4K size=404K [0.064s][info][gc ] Using Serial [0.065s][info][cds ] UseSharedSpaces: Specified shared archive not found. [0.068s][info][startuptime ] Genesis, 0.0438007 secs [0.068s][info][startuptime ] TemplateTable initialization, 0.0001120 secs I am also still trying to build the mainline jdk as suggested, but I am currently facing some difficulties with that as the toolchain I was using before did not meet the minimum requirements for gcc (toolchain is 4.8.5) and I am trying to get one working with a newer gcc. I was also unable to use the builds you have linked, as the system's glibc I'm using (2.18) is also too outdated to run those. ________________________________ From: David Holmes Sent: Sunday, October 10, 2021 6:22 PM To: Aleksey Shipilev ; John Cummings ; build-dev at openjdk.java.net Subject: Re: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A On 9/10/2021 3:58 pm, Aleksey Shipilev wrote: > Hi, > > This does not look a build issue per se, but rather a Hotspot bug. The SIGILL in ThreadGroup.add looks to me like an issue with atomic operations as that is the first synchronized method that gets executed during VM initialization. David ----- > On 10/8/21 7:46 PM, John Cummings wrote: >> I am using the source from https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk11&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jyGhwNIDDVhS7utnPcjXqOC2shrtsc7jd7sf3rQK4Io%3D&reserved=0. > > This is an extremely old JDK 11 tree. The most actual one is here: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk11u-dev%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fOVVWMdwPE681Q%2FqlsoxWU4T8HIekEVcBA8ZDFENqJg%3D&reserved=0 > > FWIW, ARM32 builds from that repo work for me on RPi 4: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.shipilev.net%2Fopenjdk-jdk11-dev%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A6i3DI%2BEmzKi2Ol%2FMMFV1w1F%2B6W272yhoy1BoWqHYEk%3D&reserved=0 > >> I am at the point where I am unsure where to proceed or what to >> change, and haven't been able to >> find a solution anywhere thus far to build a client version of >> OpenJDK-11. If there's any >> additional information I can/should provide, please let me know. > > Additional things to try: > *) Build fastdebug, trying to see if any VM assert is triggered; pass > --with-debug-level=fastdebug to configure > *) Build/test the JDK mainline (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FtvfBXp9aewGzl8lIRQYzBAl6E05tytgZwMF4l4lsR4%3D&reserved=0), > trying to see if this is a fixed issue that is missing a 11u backport > *) Trim down --with-extra-cflags and --with-extra-cxxflags, looking > for some special flag that triggers the bug > > There were plenty of ARM32 bugs fixed (backported) in 11u, but I also > see some that are only fixed in later JDKs, for example: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8222825&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FC1gnVjYaeqeLxs8W4ZMSbw7enjBH%2Fl81Z2x5%2FUkyLo%3D&reserved=0 > The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. From david.holmes at oracle.com Wed Oct 13 21:48:17 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2021 07:48:17 +1000 Subject: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A In-Reply-To: References:

<618eb555-c987-6f25-ab8c-2143900d6c5c@oracle.com> Message-ID: <14bfadca-0213-90be-6792-860f8d498ea5@oracle.com> Hi John, On 14/10/2021 3:20 am, John Cummings wrote: > Thank you both for the responses! > > I am now using the https://github.com/openjdk/jdk11u-dev/ > tree that you linked and I have > trimmed down my cxxflags and cflags to just -O2 and -pipe, and added I would not mess with the optimisation level. The crash looks like the wrong instruction is being used, possibly due to the forced optimisation level. David ----- > --with-debug-level=fastdebug. I've tried with zero build, which still > works, but server, client still crash immediately, but now they also > give me an assert internal error: > > Server: > > # > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: ?SuppressErrorAt=/assembler_arm.hpp:240 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?Internal Error > (/home/johnc/Documents/openjdk/jdk11u-dev/src/hotspot/cpu/arm/assembler_arm.hpp:240), > pid=1467, tid=1468 > # ?assert(_disp == 0 && (_shift_imm >> 5) == 0) failed: encoding constraint > # > # JRE version: ?(11.0.14) (fastdebug build ) > # Java VM: OpenJDK Server VM (fastdebug > 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode, serial gc, linux-) > # Core dump will be written. Default location: > /usr/lib/jvm/jdk11/server/jdk/bin/core > # > > Client: > > # > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: ?SuppressErrorAt=/assembler_arm.hpp:240 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?Internal Error > (/home/johnc/Documents/openjdk/jdk11u-dev/src/hotspot/cpu/arm/assembler_arm.hpp:240), > pid=1296, tid=1297 > # ?assert(_disp == 0 && (_shift_imm >> 5) == 0) failed: encoding constraint > # > # JRE version: ?(11.0.14) (fastdebug build ) > # Java VM: OpenJDK Client VM (fastdebug > 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode, serial gc, linux-) > # Core dump will be written. Default location: > /usr/lib/jvm/jdk11/client/jre/bin/core > # > > And if it helps, here's the output of -Xlog:all on the client fastdebug > build > > # ./java -Xlog:all > [0.012s][info][os] Use of CLOCK_MONOTONIC is supported > [0.012s][info][os] Use of pthread_condattr_setclock is supported > [0.012s][info][os] Relative timed-wait using pthread_cond_timedwait is > associated with CLOCK_MONOTONIC > [0.012s][info][os] HotSpot is running with glibc 2.18, NPTL 2.18 > [0.013s][info][os] SafePoint Polling address: 0xb6f03000 > [0.016s][info][biasedlocking] Aligned thread 0xb5f17160 to 0xb5f17400 > [0.016s][info][os,thread ? ?] Thread attached (tid: 1484, pthread id: > 3054040160). > [0.018s][info][os ? ? ? ? ? ] attempting shared library load of > /usr/lib/jvm/jdk11/client/jdk/lib/libzip.so > [0.019s][info][os ? ? ? ? ? ] shared library load of > /usr/lib/jvm/jdk11/client/jdk/lib/libzip.so was successful > [0.020s][info][class,path ? ] bootstrap loader class > path=/usr/lib/jvm/jdk11/client/jdk/lib/modules > [0.020s][info][class,path ? ] opened: > /usr/lib/jvm/jdk11/client/jdk/lib/modules > [0.020s][info][class,load ? ] opened: > /usr/lib/jvm/jdk11/client/jdk/lib/modules > [0.020s][info][pagesize ? ? ] CodeCache: ?min=160K max=32M > base=0xb3d5f000 page_size=4K size=32M > [0.022s][info][os,cpu ? ? ? ] CPU:total 2 (initial active 2) (ARMv7), vfp > [0.022s][info][os,cpu ? ? ? ] > /proc/cpuinfo: > [0.022s][info][os,cpu ? ? ? ] Processor : ARMv7 Processor rev 4 (v7l) > processor ? ? ? : 0 > BogoMIPS ? ? ? ?: 1810.43 > > processor ? ? ? : 1 > BogoMIPS ? ? ? ?: 1823.53 > > Features ? ? ? ?: swp half thumb fastmult vfp edsp thumbee neon vfpv3 > tls vfpv4 idiva idivt > CPU implementer : 0x41 > CPU architecture: 7 > CPU variant ? ? : 0x0 > CPU part ? ? ? ?: 0xc07 > CPU revision ? ?: 4 > > Hardware ? ? ? ?: sun7i > Revision ? ? ? ?: 0000 > Serial ? ? ? ? ?: 07c1120f5552484880758685165166cb > [0.022s][info][os,cpu ? ? ? ] Online cpus: > [0.022s][info][os,cpu ? ? ? ] 0-1 > [0.022s][info][os,cpu ? ? ? ] Offline cpus: > [0.023s][info][os,cpu ? ? ? ] > [0.024s][info][startuptime ?] StubRoutines generation 1, 0.0007363 secs > [0.025s][info][pagesize ? ? ] Heap: ?min=6M max=200M base=0xa7400000 > page_size=2M size=200M > [0.025s][info][pagesize ? ? ] Card Table: ?min=409601B max=409601B > base=0xb3c7a000 page_size=4K size=404K > [0.064s][info][gc ? ? ? ? ? ] Using Serial > [0.065s][info][cds ? ? ? ? ?] UseSharedSpaces: Specified shared archive > not found. > [0.068s][info][startuptime ?] Genesis, 0.0438007 secs > [0.068s][info][startuptime ?] TemplateTable initialization, 0.0001120 secs > > > > I am also still trying to build the mainline jdk as suggested, but I am > currently facing some difficulties with that as the toolchain I was > using before did not meet the minimum requirements for gcc (toolchain is > 4.8.5) and I am trying to get one working with a newer gcc. I was also > unable to use the builds you have linked, as the system's glibc I'm > using (2.18) is also too outdated to run those. > > > > > ------------------------------------------------------------------------ > *From:* David Holmes > *Sent:* Sunday, October 10, 2021 6:22 PM > *To:* Aleksey Shipilev ; John Cummings > ; build-dev at openjdk.java.net > > *Subject:* Re: Unable to build Client/Server variant for OpenJDK-11 on > ARMv7-A > On 9/10/2021 3:58 pm, Aleksey Shipilev wrote: >> Hi, >> >> This does not look a build issue per se, but rather a Hotspot bug. > > The SIGILL in ThreadGroup.add looks to me like an issue with atomic > operations as that is the first synchronized method that gets executed > during VM initialization. > > David > ----- > >> On 10/8/21 7:46 PM, John Cummings wrote: >>> I am using the source from https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk11&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jyGhwNIDDVhS7utnPcjXqOC2shrtsc7jd7sf3rQK4Io%3D&reserved=0 > . >> >> This is an extremely old JDK 11 tree. The most actual one is here: >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk11u-dev%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fOVVWMdwPE681Q%2FqlsoxWU4T8HIekEVcBA8ZDFENqJg%3D&reserved=0 > >> >> FWIW, ARM32 builds from that repo work for me on RPi 4: >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuilds.shipilev.net%2Fopenjdk-jdk11-dev%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A6i3DI%2BEmzKi2Ol%2FMMFV1w1F%2B6W272yhoy1BoWqHYEk%3D&reserved=0 > >> >>> I am at the point where I am unsure where to proceed or what to >>> change, and haven't been able to >>> find a solution anywhere thus far to build a client version of >>> OpenJDK-11. If there's any >>> additional information I can/should provide, please let me know. >> >> Additional things to try: >>?? *) Build fastdebug, trying to see if any VM assert is triggered; pass >> --with-debug-level=fastdebug to configure >>?? *) Build/test the JDK mainline (https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2F&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FtvfBXp9aewGzl8lIRQYzBAl6E05tytgZwMF4l4lsR4%3D&reserved=0 > ), >> trying to see if this is a fixed issue that is missing a 11u backport >>?? *) Trim down --with-extra-cflags and --with-extra-cxxflags, looking >> for some special flag that triggers the bug >> >> There were plenty of ARM32 bugs fixed (backported) in 11u, but I also >> see some that are only fixed in later JDKs, for example: >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8222825&data=04%7C01%7CJohnC%40synel-americas.com%7C7c661821d3f5486b0f1a08d98c559ee9%7Cce62291737b444dcb33e6a5ae5e16b70%7C0%7C0%7C637695121667542808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=FC1gnVjYaeqeLxs8W4ZMSbw7enjBH%2Fl81Z2x5%2FUkyLo%3D&reserved=0 > >> > The information contained in this message may be privileged, > confidential, and protected from disclosure. If the reader of this > message is not the intended recipient, or any employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any dissemination, distribution, or copying of > this communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by replying to the > message and deleting it from your computer. Thank you. From aph at openjdk.java.net Thu Oct 14 09:49:48 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Oct 2021 09:49:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. So I figured out how to build it with `make build-hsdis`. The instructions need to be fixed. Two problems: firstly, the library seems to be built with the wrong name, so the runtime doesn't find it. I had to use `ln -sf ~/lib/libhsdis.dylib ~/lib/hsdis-aarch64.dylib` to get it to work. More severely, the disassembly is truncated, so lots of stuff doesn't work. The binutils-based hsdis prints 0x00000001105665b4: stp wzr, wzr, [x20, #60] ;*putfield preCounterBlock {reexecute=0 rethrow=0 return_oop=0} ; - com.sun.crypto.provider.GaloisCounterMode$GCMEngine::@80 (line 673) ; - com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt::@8 (line 1346) ; - com.sun.crypto.provider.GaloisCounterMode::checkInit at 60 (line 329) ;; B6: # out( B242 B7 ) <- in( B192 B5 ) Freq: 0.999999 0x00000001105665b8: cbnz x21, 0x00000001105665c8 ;; null oop passed to encode_heap_oop_not_null2 0x00000001105665bc: dcps1 #0xdeae 0x00000001105665c0: .inst 0x082adca6 ; undefined 0x00000001105665c4: udf #1 0x00000001105665c8: lsr x10, x21, #3 ;*invokevirtual getLongUnaligned {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.invoke.VarHandleByteArrayAsLongs$ArrayHandle::get at 32 (line 115) ... lots more but the llvm-based one stops here: 0x000000010ed79034: stp wzr, wzr, [x20, #0x3c];*putfield preCounterBlock {reexecute=0 rethrow=0 return_oop=0} ; - com.sun.crypto.provider.GaloisCounterMode$GCMEngine::@80 (line 673) ; - com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt::@8 (line 1346) ; - com.sun.crypto.provider.GaloisCounterMode::checkInit at 60 (line 329) ;; B6: # out( B242 B7 ) <- in( B192 B5 ) Freq: 0.999999 0x000000010ed79038: cbnz x21, #0x10 ;; null oop passed to encode_heap_oop_not_null2 0x000000010ed7903c: dcps1 #0xdeae 0x000000010ed79040: -------------------------------------------------------------------------------- [/Disassembly] I think it's giving up as soon as it sees something it doesn't recognize, so it's pretty much useless. In addition, even when it does work the LLVM disassembly is pretty poor. For example, the unverified entry point looks like 0x000000010ed78f80: ldr w8, [x1, #0x8] 0x000000010ed78f84: cmp w9, w8 0x000000010ed78f88: b.eq #0x10 0x000000010ed78f8c: adrp x8, #-128524288 ; {runtime_call ic_miss_stub} 0x000000010ed78f90: add x8, x8, #0x1c0 0x000000010ed78f94: br x8 instead of 0x0000000110566500: ldr w8, [x1, #8] 0x0000000110566504: cmp w9, w8 0x0000000110566508: b.eq 0x0000000110566518 // b.none 0x000000011056650c: adrp x8, 0x0000000108ae6000 ; {runtime_call ic_miss_stub} 0x0000000110566510: add x8, x8, #0x1c0 0x0000000110566514: br x8 Sure, it's good to have a choice, but the LLVM-based hsdis doesn't look to me like a serious alternative for professional work. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From ihse at openjdk.java.net Thu Oct 14 12:54:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 14 Oct 2021 12:54:52 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: On Thu, 14 Oct 2021 09:46:47 GMT, Andrew Haley wrote: >> This patch expands the newly added system for hsdis backends to include LLVM. >> >> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) >> >> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. >> >> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. > > So I figured out how to build it with `make build-hsdis`. The instructions need to be fixed. > > Two problems: firstly, the library seems to be built with the wrong name, so the runtime doesn't find it. I had to use > `ln -sf ~/lib/libhsdis.dylib ~/lib/hsdis-aarch64.dylib` > to get it to work. > > More severely, the disassembly is truncated, so lots of stuff doesn't work. The binutils-based hsdis prints > > > 0x00000001105665b4: stp wzr, wzr, [x20, #60] ;*putfield preCounterBlock {reexecute=0 rethrow=0 return_oop=0} > ; - com.sun.crypto.provider.GaloisCounterMode$GCMEngine::@80 (line 673) > ; - com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt::@8 (line 1346) > ; - com.sun.crypto.provider.GaloisCounterMode::checkInit at 60 (line 329) > ;; B6: # out( B242 B7 ) <- in( B192 B5 ) Freq: 0.999999 > 0x00000001105665b8: cbnz x21, 0x00000001105665c8 > ;; null oop passed to encode_heap_oop_not_null2 > 0x00000001105665bc: dcps1 #0xdeae > 0x00000001105665c0: .inst 0x082adca6 ; undefined > 0x00000001105665c4: udf #1 > 0x00000001105665c8: lsr x10, x21, #3 ;*invokevirtual getLongUnaligned {reexecute=0 rethrow=0 return_oop=0} > ; - java.lang.invoke.VarHandleByteArrayAsLongs$ArrayHandle::get at 32 (line 115) > ... lots more > > > but the llvm-based one stops here: > > > 0x000000010ed79034: stp wzr, wzr, [x20, #0x3c];*putfield preCounterBlock {reexecute=0 rethrow=0 return_oop=0} > ; - com.sun.crypto.provider.GaloisCounterMode$GCMEngine::@80 (line 673) > ; - com.sun.crypto.provider.GaloisCounterMode$GCMDecrypt::@8 (line 1346) > ; - com.sun.crypto.provider.GaloisCounterMode::checkInit at 60 (line 329) > ;; B6: # out( B242 B7 ) <- in( B192 B5 ) Freq: 0.999999 > 0x000000010ed79038: cbnz x21, #0x10 > ;; null oop passed to encode_heap_oop_not_null2 > 0x000000010ed7903c: dcps1 #0xdeae > 0x000000010ed79040: -------------------------------------------------------------------------------- > [/Disassembly] > > > > I think it's giving up as soon as it sees something it doesn't recognize, so it's pretty much useless. > > In addition, even when it does work the LLVM disassembly is pretty poor. For example, the unverified entry point looks like > > > 0x000000010ed78f80: ldr w8, [x1, #0x8] > 0x000000010ed78f84: cmp w9, w8 > 0x000000010ed78f88: b.eq #0x10 > 0x000000010ed78f8c: adrp x8, #-128524288 ; {runtime_call ic_miss_stub} > 0x000000010ed78f90: add x8, x8, #0x1c0 > 0x000000010ed78f94: br x8 > > > instead of > > > 0x0000000110566500: ldr w8, [x1, #8] > 0x0000000110566504: cmp w9, w8 > 0x0000000110566508: b.eq 0x0000000110566518 // b.none > 0x000000011056650c: adrp x8, 0x0000000108ae6000 ; {runtime_call ic_miss_stub} > 0x0000000110566510: add x8, x8, #0x1c0 > 0x0000000110566514: br x8 > > > Sure, it's good to have a choice, but the LLVM-based hsdis doesn't look to me like a serious alternative for professional work. @theRealAph Yes, the build instructions needs to be updated. I could have sworn I did that, but maybe that fix is just lying around un-committed in one of my repos on one of my test computers. I'll have to go around and check. Or write it again if I can't fix it. That needs to go with this PR. You can do `make install-hsdis` to avoid doing the symlinking yourself. As Jorn pointed out, there is currently a bug in that the library does not get copied from the "exploded jdk" to the image. I will fix that in an upcoming commit to this PR. As for LLVM not giving you a good user experience; I can't really tell what's wrong. Apparently @luhenry (and @JornVernee I believe) has used this. I'm not really the target audience myself; I'm only trying to make it possible to use. If it is so severly limited as you say maybe this isn't worth pursuing. Some feedback from those who have tested it would be appeciated here, to help med understand if this patch should be dropped. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From shade at redhat.com Thu Oct 14 13:08:21 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 Oct 2021 15:08:21 +0200 Subject: Unable to build Client/Server variant for OpenJDK-11 on ARMv7-A In-Reply-To: References:

<618eb555-c987-6f25-ab8c-2143900d6c5c@oracle.com> Message-ID: <18cfb440-8e7b-e44d-e697-1a787cffd819@redhat.com> On 10/13/21 7:20 PM, John Cummings wrote: > Thank you both for the responses! > > I am now using the https://github.com/openjdk/jdk11u-dev/ > tree that you linked and I have trimmed down my cxxflags and cflags to just -O2 and -pipe, and added > --with-debug-level=fastdebug. I've tried with zero build, which still works, but server, client > still crash immediately, but now they also give me an assert internal error: > > Server: > > # > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: ?SuppressErrorAt=/assembler_arm.hpp:240 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # ?Internal Error > (/home/johnc/Documents/openjdk/jdk11u-dev/src/hotspot/cpu/arm/assembler_arm.hpp:240), pid=1467, tid=1468 > # ?assert(_disp == 0 && (_shift_imm >> 5) == 0) failed: encoding constraint > # > # JRE version: ?(11.0.14) (fastdebug build ) > # Java VM: OpenJDK Server VM (fastdebug 11.0.14-internal+0-adhoc.johnc.jdk11u-dev, mixed mode, > serial gc, linux-) > # Core dump will be written. Default location: /usr/lib/jvm/jdk11/server/jdk/bin/core OK, good. This indicates that ARM backend had tried to encode some instruction that is beyond ARM spec. It makes sense that release builds SIGILL when than happens: the instruction is garbage. The next step is to look into hs_err and see the call stack for that assert, which would drive you to Hotspot code. From the code inspection, that is likely to be assembler_arm.hpp:encoding2(), which is called from pld/pldw instructions... It looks suspiciously like: https://bugs.openjdk.java.net/browse/JDK-8222825 ...so maybe you want to try to apply this patch and build again: https://cr.openjdk.java.net/~bulasevich/8222825/webrev.00.jdk11/ -- Thanks, -Aleksey From weijun at openjdk.java.net Thu Oct 14 13:44:00 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Oct 2021 13:44:00 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 Message-ID: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. ------------- Commit messages: - 8275252: Migrate cacerts from JKS to password-less PKCS12 Changes: https://git.openjdk.java.net/jdk/pull/5948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275252 Stats: 81 lines in 3 files changed: 2 ins; 69 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/5948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5948/head:pull/5948 PR: https://git.openjdk.java.net/jdk/pull/5948 From erikj at openjdk.java.net Thu Oct 14 13:57:49 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 14 Oct 2021 13:57:49 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/5948 From aph at openjdk.java.net Thu Oct 14 14:06:54 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 14 Oct 2021 14:06:54 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: On Wed, 13 Oct 2021 07:26:21 GMT, Ludovic Henry wrote: >> This patch expands the newly added system for hsdis backends to include LLVM. >> >> The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) >> >> Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. >> >> The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. > > Very happy to see it landing :) Thank you! > > I don't have access to a windows machine, and even less a Windows-AArch64 machine. @lewurm would you be able to take a look? > As for LLVM not giving you a good user experience; I can't really tell what's wrong. Apparently @luhenry (and @JornVernee I believe) has used this. I'm not really the target audience myself; I'm only trying to make it possible to use. If it is so severly limited as you say maybe this isn't worth pursuing. Some feedback from those who have tested it would be appeciated here, to help med understand if this patch should be dropped. I don't think it should be dropped, but I imagine that the bugs can be fixed. If LLVM's disassembler always dies as soon as it sees something it can't recognize, I'm astonished. Maybe the LLVM I'm using is bad. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From jvernee at openjdk.java.net Thu Oct 14 14:17:51 2021 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 14 Oct 2021 14:17:51 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: <2mM80GN7cgb99W91FnCDP13DGr4LUPXCr0iRdO-JqQQ=.25d0f1ce-b4b8-4e2d-811d-c9268c500bf2@github.com> On Thu, 14 Oct 2021 14:04:12 GMT, Andrew Haley wrote: > Some feedback from those who have tested it would be appeciated here I haven't really tested it beyond building the lib and seeing if assembly was output instead of just bytes, so I can't really comment on that I'm afraid. Since the binutils hsdis wasn't buildable on Windows for me in the past, I've always been using the [fcml based hsdis](https://github.com/swojtasiak/fcml-lib/tree/master/example/hsdis) on Windows. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From duke at openjdk.java.net Thu Oct 14 15:45:50 2021 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 14 Oct 2021 15:45:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: <5kwYGe1i7vi-xErsqesfSObRYkyV_7GvjrfHyxyARnY=.a1fc7c37-6f07-4ab8-81f5-674e83ba8fa1@github.com> On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. I don't understand how this can work at all. I wrote a custom `CertDownloader` for our company use where I wanted to migrate to PKCS#12. Suddenly all of my applications started to fail on OpenJDK8u until I have figured out that PKCS#12 was not designed to be passwordless and due to the missing ecryption the trusted CA aren't visible. This bug is known as: * https://bugs.openjdk.java.net/browse/JDK-8231107 * https://bugs.openjdk.java.net/browse/JDK-8194702 I had to revert to JKS for now. Unless those drizzle down to 8u, 11u, 17u this is going to be hard. I still would love to see a trust store (not key store) which either reads OpenSSL's [`CAfile` or `CApath`](https://www.openssl.org/docs/man1.1.0/man3/SSL_CTX_load_verify_locations.html). This would greatly improve compat between Java and the OS default store on may OS, e.g., Debian, FreeBSD, RHEL, etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From weijun at openjdk.java.net Thu Oct 14 17:34:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Oct 2021 17:34:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. If you look into the code change for `make/ToolsJdk.gmk`, you can see 2 system properties used while generating the new cacerts file. With them, the new file becomes password-less. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From duke at openjdk.java.net Thu Oct 14 19:10:50 2021 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 14 Oct 2021 19:10:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 17:31:26 GMT, Weijun Wang wrote: > > > If you look into the code change for `make/ToolsJdk.gmk`, you can see 2 system properties used while generating the new cacerts file. With them, the new file becomes password-less. This I have seen, but what about: * Generating this trust store with Java code like I do? * Will this solve the two mentioned tickets? ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From weijun at openjdk.java.net Thu Oct 14 19:26:47 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Oct 2021 19:26:47 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>

Message-ID: On Thu, 14 Oct 2021 19:07:55 GMT, Michael Osipov wrote: > Generating this trust store with Java code like I do? What do you mean "like you do"? If you accept the proposed format in this PR, then just follow what `GenerateCACerts.java` is doing and how it's called. If you are thinking about reading the openssl trust store, that's not what this PR is for. This PR intends to find a modern format that is 100% interoperable with older JDK releases. As for the other two tickets, they are related. If JDK-8231107 is resolved, then there's no need to set the 2 system properties. JDK-8194702 is not fixable because the certificates are already encrypted. Instead, https://bugs.openjdk.java.net/browse/JDK-8274913 was proposed, but only newly generated keystores after it will get the benefit. Still, this PR does not depend on the other two tickets. This PR is about one single keystore -- cacerts -- which can be treated special. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From duke at openjdk.java.net Thu Oct 14 19:40:51 2021 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 14 Oct 2021 19:40:51 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. Let me summarize/rephrase your last message: To trick in the Makefile and the changed Java code (same way as I do in my code) produce a password-less truststore. Now since JDK-8231107 depicts that loading with a null password does not work the same way as with JKS this means that JDK-8231107 must also be applied to all supported JDK versions to make the output of this PR usable. Doesn't it? Note: JDK-8274913 is not publically available and I don't have a JBS account also I do report issues with Apache projects to Rory O'Donnell sometimes. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From weijun at openjdk.java.net Thu Oct 14 19:53:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Oct 2021 19:53:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. No, this PR is totally independent. Once a password-less pkcs12 file is generated, it can be read by any JDK since JDK 7u with a null password and the certs are visible. The other 2 tickets are all about storing, storing with a null password, storing with a default algorithm. I've made JDK-8274913 public. It's just an idea and not proposed to any release. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From duke at openjdk.java.net Thu Oct 14 20:01:47 2021 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 14 Oct 2021 20:01:47 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 19:50:33 GMT, Weijun Wang wrote: > > > No, this PR is totally independent. Once a password-less pkcs12 file is generated, it can be read by any JDK since JDK 7u with a null password and the certs are visible. The other 2 tickets are all about storing, storing with a null password, storing with a default algorithm. > > I've made JDK-8274913 public. It's just an idea and not proposed to any release. OK, now I see. This makes sense now. Storing is a different and as I see in your code somewhere `NONE` needs to be provided and it is not obvious apparently. Storing will remain a pain in all JDK versions unless JDK-8274913 is implemented which will solve JDK-8231107. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From weijun at openjdk.java.net Thu Oct 14 20:06:49 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 14 Oct 2021 20:06:49 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. For password-less pksc12, JDK-8231107 is more relevant. JDK-8274913 still has MacData, which is quite useless for cacerts, and leaving a well-known password there is awkward. ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From duke at openjdk.java.net Thu Oct 14 20:06:50 2021 From: duke at openjdk.java.net (Michael Osipov) Date: Thu, 14 Oct 2021 20:06:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 20:02:32 GMT, Weijun Wang wrote: > > > For password-less pksc12, JDK-8231107 is more relevant. JDK-8274913 still has MacData, which is quite useless for cacerts, and leaving a well-known password there is awkward. Agree, makes sense. BTW: https://github.com/ctron/pem-keystore#reading-a-ca-bundle ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From luhenry at openjdk.java.net Fri Oct 15 08:22:48 2021 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 15 Oct 2021 08:22:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. The value add of this LLVM-based hsdis is two-fold: - It supports platforms that aren't supported by binutils (Windows-AArch64 for example) - The license being more permissive would allow to build it as part of the OpenJDK build more easily (and even maybe ship it?) LLVM has a strong track record of supporting new platforms (Windows-AArch64 and macOS-AArch64 for example, mostly because of investment from Microsoft and Apple respectively), and `hsdis` is a necessary tool for porting the OpenJDK to any new platform. Since the maintenance is fairly low (small codebase, small and knowledgable user base), I would be biased towards including it with appropriate warnings. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From mullan at openjdk.java.net Fri Oct 15 14:04:48 2021 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 15 Oct 2021 14:04:48 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74: > 72: cert = (X509Certificate) cf.generateCertificate(fis); > 73: } > 74: ks.setCertificateEntry(alias, cert); In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this? ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From ihse at openjdk.java.net Fri Oct 15 14:15:52 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 15 Oct 2021 14:15:52 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Fri, 15 Oct 2021 14:02:15 GMT, Sean Mullan wrote: >> The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. > > make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74: > >> 72: cert = (X509Certificate) cf.generateCertificate(fis); >> 73: } >> 74: ks.setCertificateEntry(alias, cert); > > In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this? If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From monica.beckwith at gmail.com Fri Oct 15 14:53:36 2021 From: monica.beckwith at gmail.com (monica beckwith) Date: Fri, 15 Oct 2021 09:53:36 -0500 Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: Hi all, I am on vacation right now, but we can take a look next week and see how we can support the LLVM backend for hsdis. It is much required by Windows-AArch64 and we would hate for all the good work to not make it upstream. Monica Sent from my Arm powered smart device. On Thu, Oct 14, 2021, 9:07 AM Andrew Haley wrote: > On Wed, 13 Oct 2021 07:26:21 GMT, Ludovic Henry > wrote: > > >> This patch expands the newly added system for hsdis backends to include > LLVM. > >> > >> The actual code in hsdis-llvm.cpp is based heavily on the work by > @luhenry, as published in the never integrated PR > https://github.com/openjdk/jdk/pull/392. (I have basically just ripped > out the binutils-based part of it.) > >> > >> Unfortunately I have not been able to make this work properly on > Windows. With some additional flags I made it compile without complaints, > but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` > when I tried to load the library. This is somewhat ironic, since the > initial implementation was created by Ludovic for the very purpose of using > it on Windows. > >> > >> The lack of Windows support in this patch does not mean it is > impossible to get it to work, just that I need to co-operate with someone > who has more experience of compiling LLVM on Windows, and/or are more eager > to get this combination to work. > > > > Very happy to see it landing :) Thank you! > > > > I don't have access to a windows machine, and even less a > Windows-AArch64 machine. @lewurm would you be able to take a look? > > > As for LLVM not giving you a good user experience; I can't really tell > what's wrong. Apparently @luhenry (and @JornVernee I believe) has used > this. I'm not really the target audience myself; I'm only trying to make it > possible to use. If it is so severly limited as you say maybe this isn't > worth pursuing. Some feedback from those who have tested it would be > appeciated here, to help med understand if this patch should be dropped. > > I don't think it should be dropped, but I imagine that the bugs can be > fixed. If LLVM's disassembler always dies as soon as it sees something it > can't recognize, I'm astonished. Maybe the LLVM I'm using is bad. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/5920 > From weijun at openjdk.java.net Fri Oct 15 15:00:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 15 Oct 2021 15:00:50 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>

Message-ID: <6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com> On Fri, 15 Oct 2021 14:12:55 GMT, Magnus Ihse Bursie wrote: >> make/jdk/src/classes/build/tools/generatecacerts/GenerateCacerts.java line 74: >> >>> 72: cert = (X509Certificate) cf.generateCertificate(fis); >>> 73: } >>> 74: ks.setCertificateEntry(alias, cert); >> >> In the previous code, we always used a fixed date (cert's notBefore) for the creation date. Now, it seems it will be always different and based on when it was created. I'm not really sure if this is an issue in practice, but I think it is worth thinking about a bit more - do you have any thoughts on this? > > If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-) The certificate stored in a PKCS12 file has no date associated. Whenever you load a keystore, the creation time is set to the load time. In fact, the `VerifyCACerts.java` maintains a SHA-256 hash of the keystore and it will not change unless the certs themselves are changed. Here is the actual bytes for one certificate entry inside: 0000:1AD48 [] SEQUENCE 0005:0659 [0] SEQUENCE 0009:000D [00] OID 1.2.840.113549.1.12.10.1.3 (CertBag) 0016:05DB [01] cont [0] 001A:05D7 [010] SEQUENCE 001E:000C [0100] OID 1.2.840.113549.1.9.22.1 (CertTypeX509) 002A:05C7 [0101] cont [0] 002E:05C3 [01010] OCTET STRING (1729119956) 0000: 30 82 05 BB 30 82 03 A3 A0 03 02 01 02 02 08 57 0...0..........W 0010: 0A 11 97 42 C4 E3 CC 30 0D 06 09 2A 86 48 86 F7 ...B...0...*.H.. 0020: 0D 01 01 0B 05 00 30 6B 31 0B 30 09 06 03 55 04 ......0k1.0...U. (1471 bytes) 05F1:006D [02] SET 05F3:0053 [020] SEQUENCE 05F5:000B [0200] OID 1.2.840.113549.1.9.20 (FriendlyName) 0600:0046 [0201] SET 0602:0044 [02010] STRING "actalisauthenticationrootca [jdk]" 0646:0018 [021] SEQUENCE 0648:000E [0210] OID 2.16.840.1.113894.746875.1.1 (ORACLE_TrustedKeyUsage) 0656:0008 [0211] SET 0658:0006 [02110] OID 2.5.29.37.0 (anyExtendedKeyUsage) ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From aph at openjdk.java.net Fri Oct 15 15:38:48 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 15 Oct 2021 15:38:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: On Fri, 15 Oct 2021 08:20:05 GMT, Ludovic Henry wrote: > Since the maintenance is fairly low (small codebase, small and knowledgable user base), I would be biased towards including it with appropriate warnings. I don't think we should commit code that we know is broken. I don't believe that this view might be controversial. Maybe someone should try to reproduce the failure I've seen, and then we should look at fixing it. Maybe it's a local problem. Also, this patch breaks all current hsdis builds that follow the installation instructions. Either we get revised instructions or the build should be fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From mcimadamore at openjdk.java.net Fri Oct 15 16:54:58 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:54:58 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Fix javadoc issue in VaList * Fix bug in concurrent logic for shared scope acquire ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/27e71ee7..5ed94c30 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=03-04 Stats: 10 lines in 2 files changed: 2 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From mcimadamore at openjdk.java.net Fri Oct 15 16:56:08 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 15 Oct 2021 16:56:08 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v5] In-Reply-To: References:

Message-ID: On Fri, 15 Oct 2021 16:54:58 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * Fix javadoc issue in VaList > * Fix bug in concurrent logic for shared scope acquire src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/SharedScope.java line 138: > 136: ResourceCleanup prev = (ResourceCleanup) FST.getAcquire(this); > 137: cleanup.next = prev; > 138: ResourceCleanup newSegment = (ResourceCleanup) FST.compareAndExchangeRelease(this, prev, cleanup); In this place we can actually overwrite CLOSED_LIST (if getAcquired has seen such value). While this particular add will fail later on (since we check witness), another concurrent add might then pass, since it sees a value other than CLOSED_LIST (which is supposed to be a terminal state). Also, after consulting with @DougLea and @shipilev - it seems like using volatile semantics is the way to go here. This should fix a spurious (and very rare) failure on TestResourceScope on arm64. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From ihse at openjdk.java.net Sat Oct 16 08:15:47 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Sat, 16 Oct 2021 08:15:47 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References:

Message-ID: <0i45tJK6ikOSt-m5vD-t6utK3wvLRCkTBCcY0pIOESI=.3ea75a59-e7ea-4d5e-a9b4-10a17e299c36@github.com> On Fri, 15 Oct 2021 15:36:14 GMT, Andrew Haley wrote: >> The value add of this LLVM-based hsdis is two-fold: >> - It supports platforms that aren't supported by binutils (Windows-AArch64 for example) >> - The license being more permissive would allow to build it as part of the OpenJDK build more easily (and even maybe ship it?) >> >> LLVM has a strong track record of supporting new platforms (Windows-AArch64 and macOS-AArch64 for example, mostly because of investment from Microsoft and Apple respectively), and `hsdis` is a necessary tool for porting the OpenJDK to any new platform. Since the maintenance is fairly low (small codebase, small and knowledgable user base), I would be biased towards including it with appropriate warnings. > >> Since the maintenance is fairly low (small codebase, small and knowledgable user base), I would be biased towards including it with appropriate warnings. > > I don't think we should commit code that we know is broken. I don't believe that this view might be controversial. > Maybe someone should try to reproduce the failure I've seen, and then we should look at fixing it. Maybe it's a local problem. > > Also, this patch breaks all current hsdis builds that follow the installation instructions. Either we get revised instructions or the build should be fixed. @theRealAph We should not push broken code, and we should not break the existing build of hsdis. I fully agree with this. I will not push this patch until all reviewers are happy, so you don't need to worry about that. :) My initial plan was to get the unix platforms working in this push, and tackle Windows later on, but it seems now that it's better to keep this PR around for a bit longer instead, and fold Windows support into it as well. (Which means I'll wait for Monica to return and being able to test and help out.) I need to understand better why things are failing for you. Can you describe a reproducer? ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From mcimadamore at openjdk.java.net Sat Oct 16 11:11:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Sat, 16 Oct 2021 11:11:59 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/419 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - * use `invokeWithArguments` to simplify new test - Add test for liveness check with high-aririty downcalls (make sure that if an exception occurs in a downcall because of liveness, ref count of other resources are left intact). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/5907/files - new: https://git.openjdk.java.net/jdk/pull/5907/files/5ed94c30..a4db81fe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5907&range=04-05 Stats: 39 lines in 2 files changed: 39 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/5907.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5907/head:pull/5907 PR: https://git.openjdk.java.net/jdk/pull/5907 From aph at openjdk.java.net Mon Oct 18 09:13:48 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 18 Oct 2021 09:13:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: <8GQB2s_R1_B2jvcdUQQEw5aJyxZMlG9bb_to6Iw35zw=.6e803183-5e7c-407c-a269-1b92392b800d@github.com> On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. On 10/16/21 09:13, Magnus Ihse Bursie wrote: > @theRealAph We should not push broken code, and we should not break the existing build of hsdis. I fully agree with this. I will not push this patch until all reviewers are happy, so you don't need to worry about that. :) > > My initial plan was to get the unix platforms working in this push, and tackle Windows later on, but it seems now that it's better to keep this PR around for a bit longer instead, and fold Windows support into it as well. (Which means I'll wait for Monica to return and being able to test and help out.) > > I need to understand better why things are failing for you. Can you describe a reproducer? Sure. Create a .hotspot_compiler file containing print java.lang.String::checkIndex then ./build/macosx-aarch64-server-fastdebug/jdk/bin/java -XX:+PrintAssembly -version GNU disassembly of java.lang.String::isLatin1 prints in full, ending thusly [Exception Handler] 0x000000010a72c340: mov x19, #0xdead // #57005 ; {no_reloc} 0x000000010a72c344: mov x2, #0xa // #10 0x000000010a72c348: mov x4, #0xdead // #57005 0x000000010a72c34c: mov x5, #0xdead // #57005 0x000000010a72c350: adrp x8, 0x000000010a1c3000 ; {runtime_call handle_exception_from_callee Runtime1 stub} 0x000000010a72c354: add x8, x8, #0x1c0 0x000000010a72c358: blr x8 0x000000010a72c35c: dcps1 #0xdeae 0x000000010a72c360: .inst 0x0995f68e ; undefined 0x000000010a72c364: udf #1 [Deopt Handler Code] 0x000000010a72c368: adr x30, 0x000000010a72c368 0x000000010a72c36c: adrp x8, 0x000000010a26c000 ; {runtime_call DeoptimizationBlob} 0x000000010a72c370: add x8, x8, #0xbc0 0x000000010a72c374: br x8 -------------------------------------------------------------------------------- LLVM disassembly dies at [Exception Handler] 0x000000010672c340: mov x19, #0xdead ; {no_reloc} 0x000000010672c344: mov x2, #0xa 0x000000010672c348: mov x4, #0xdead 0x000000010672c34c: mov x5, #0xdead 0x000000010672c350: adrp x8, #-5672960 ; {runtime_call handle_exception_from_callee Runtime1 stub} 0x000000010672c354: add x8, x8, #0x1c0 0x000000010672c358: blr x8 0x000000010672c35c: dcps1 #0xdeae 0x000000010672c360: -------------------------------------------------------------------------------- This is llvm 12.0.1 from homebrew. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From ihse at openjdk.java.net Mon Oct 18 09:36:48 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Oct 2021 09:36:48 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com> Message-ID: On Thu, 14 Oct 2021 13:36:19 GMT, Weijun Wang wrote: > The cacerts file is now a password-less PKCS12 file. This make sure old code that uses a JKS KeyStore object can continuously load it using a null password (in fact, any password) and see all certificates inside. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From ihse at openjdk.java.net Mon Oct 18 09:36:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 18 Oct 2021 09:36:49 GMT Subject: RFR: 8275252: Migrate cacerts from JKS to password-less PKCS12 In-Reply-To: <6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com> References: <7q9fxhBWZ5VtDVN12jeqRPjTXAmgT6-gQmP1Mtut0pg=.3996d7a7-01ea-4829-8c13-a089ed7c5b49@github.com>

<6yXAA76EWqiG9yTID2x0gyUYFy4EsM4Veo1QHgRtzFQ=.4397d5c5-fcae-4649-9042-d0670ef0ec94@github.com> Message-ID: On Fri, 15 Oct 2021 14:56:23 GMT, Weijun Wang wrote: >> If that means the build will become non-reproducible, then *I* certainly have thoughts about it! ;-) > > The certificate stored in a PKCS12 file has no date associated. Whenever you load a keystore, the creation time is set to the load time. > > In fact, the `VerifyCACerts.java` maintains a SHA-256 hash of the keystore and it will not change unless the certs themselves are changed. > > Here is the actual bytes for one certificate entry inside: > > 0000:1AD48 [] SEQUENCE > 0005:0659 [0] SEQUENCE > 0009:000D [00] OID 1.2.840.113549.1.12.10.1.3 (CertBag) > 0016:05DB [01] cont [0] > 001A:05D7 [010] SEQUENCE > 001E:000C [0100] OID 1.2.840.113549.1.9.22.1 (CertTypeX509) > 002A:05C7 [0101] cont [0] > 002E:05C3 [01010] OCTET STRING (1729119956) > 0000: 30 82 05 BB 30 82 03 A3 A0 03 02 01 02 02 08 57 0...0..........W > 0010: 0A 11 97 42 C4 E3 CC 30 0D 06 09 2A 86 48 86 F7 ...B...0...*.H.. > 0020: 0D 01 01 0B 05 00 30 6B 31 0B 30 09 06 03 55 04 ......0k1.0...U. (1471 bytes) > 05F1:006D [02] SET > 05F3:0053 [020] SEQUENCE > 05F5:000B [0200] OID 1.2.840.113549.1.9.20 (FriendlyName) > 0600:0046 [0201] SET > 0602:0044 [02010] STRING "actalisauthenticationrootca [jdk]" > 0646:0018 [021] SEQUENCE > 0648:000E [0210] OID 2.16.840.1.113894.746875.1.1 (ORACLE_TrustedKeyUsage) > 0656:0008 [0211] SET > 0658:0006 [02110] OID 2.5.29.37.0 (anyExtendedKeyUsage) As long as the file content is not date dependent, I'm happy :) ------------- PR: https://git.openjdk.java.net/jdk/pull/5948 From aph at openjdk.java.net Mon Oct 18 10:12:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 18 Oct 2021 10:12:51 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: <8GQB2s_R1_B2jvcdUQQEw5aJyxZMlG9bb_to6Iw35zw=.6e803183-5e7c-407c-a269-1b92392b800d@github.com> References: <8GQB2s_R1_B2jvcdUQQEw5aJyxZMlG9bb_to6Iw35zw=.6e803183-5e7c-407c-a269-1b92392b800d@github.com> Message-ID: On Mon, 18 Oct 2021 09:10:32 GMT, Andrew Haley wrote: > >Can you describe a reproducer? > Sure. Create a .hotspot_compiler file containing print java.lang.String::checkIndex then Sorry, thinko. You don't need the .hotspot_compiler file ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From michaelm at openjdk.java.net Mon Oct 18 11:43:52 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 18 Oct 2021 11:43:52 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References:

Message-ID: On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Minor rewording of bind address output > - Merge branch 'master' into simpleserver > - Merge branch 'master' into simpleserver > - update output for all interfaces > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200: > 198: */ > 199: // @Test(dataProvider = "commonExtensions") > 200: public static void testCommonExtensions(String extension) { Is this test and the one below supposed to be commented out? ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From jboes at openjdk.java.net Mon Oct 18 12:21:59 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 18 Oct 2021 12:21:59 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References:

Message-ID: On Mon, 18 Oct 2021 11:38:22 GMT, Michael McMahon wrote: >> Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: >> >> - Minor rewording of bind address output >> - Merge branch 'master' into simpleserver >> - Merge branch 'master' into simpleserver >> - update output for all interfaces >> - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces >> - Merge branch 'master' into simpleserver >> - change default bind address from anylocal to loopback >> - address PR comments >> - Merge branch 'master' into simpleserver >> - Merge remote-tracking branch 'origin/simpleserver' into simpleserver >> - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 > > test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java line 200: > >> 198: */ >> 199: // @Test(dataProvider = "commonExtensions") >> 200: public static void testCommonExtensions(String extension) { > > Is this test and the one below supposed to be commented out? Yes, `testCommonExtensions` is a manual test to find common mime types that are currently not supported, `printUnsupportedFileExtensions` prints the list of types found. ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From michaelm at openjdk.java.net Mon Oct 18 13:58:55 2021 From: michaelm at openjdk.java.net (Michael McMahon) Date: Mon, 18 Oct 2021 13:58:55 GMT Subject: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v9] In-Reply-To: References:

Message-ID: <2Fk3re4SLz7A9vMEvJItkQfB7BCLhzAuQRoD5KXfUoc=.66a62f2d-36e0-4d53-bbb0-cca2f9cd110e@github.com> On Tue, 12 Oct 2021 10:40:15 GMT, Julia Boes wrote: >> This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. >> >> This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. >> >> The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. >> >> Additionally, a small API is introduced for programmatic creation and customization. >> >> Testing: tier1-3. > > Julia Boes has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: > > - Minor rewording of bind address output > - Merge branch 'master' into simpleserver > - Merge branch 'master' into simpleserver > - update output for all interfaces > - use ipv4/ipv6 specific loopback address and add add how-to output for all interfaces > - Merge branch 'master' into simpleserver > - change default bind address from anylocal to loopback > - address PR comments > - Merge branch 'master' into simpleserver > - Merge remote-tracking branch 'origin/simpleserver' into simpleserver > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b1b66965...e86609d0 Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From dholmes at openjdk.java.net Tue Oct 19 02:27:48 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 19 Oct 2021 02:27:48 GMT Subject: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v6] In-Reply-To: References:

Message-ID: On Sat, 16 Oct 2021 11:11:59 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-419 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/419 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - * use `invokeWithArguments` to simplify new test > - Add test for liveness check with high-aririty downcalls > (make sure that if an exception occurs in a downcall because of liveness, > ref count of other resources are left intact). Hotspot changes seem fine. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/5907 From ngasson at openjdk.java.net Tue Oct 19 04:32:47 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 19 Oct 2021 04:32:47 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. The problem is `LLVMDisasmInstruction()` returns zero size as soon as it hits an instruction it doesn't understand. Something kludgy like this works: diff --git a/src/utils/hsdis/llvm/hsdis-llvm.cpp b/src/utils/hsdis/llvm/hsdis-llvm.cpp index a491082f14fa..3c50ee8e3b40 100644 --- a/src/utils/hsdis/llvm/hsdis-llvm.cpp +++ b/src/utils/hsdis/llvm/hsdis-llvm.cpp @@ -307,6 +307,10 @@ class hsdis_backend : public hsdis_backend_base { virtual size_t decode_instruction(uintptr_t p, uintptr_t start, uintptr_t end) { char buf[128]; size_t size = LLVMDisasmInstruction(_dcontext, (uint8_t*)p, (uint64_t)(end - start), (uint64_t)p, buf, sizeof(buf)); + if (size == 0 && end - start >= 4) { + snprintf(buf, sizeof(buf), "\t.word\t#0x%08x", *(uint32_t*)p); + size = 4; + } if (size > 0) { (*_printf_callback)(_printf_stream, "%s", buf); } 0x0000ffff94685454: br x8 0x0000ffff94685458: .word #0x93e3f4c0 0x0000ffff9468545c: udf #0xffff [Exception Handler] 0x0000ffff94685460: adrp x8, #-0x795000 ; {runtime_call handle_exception_from_callee Runtime1 stub} ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From ngasson at openjdk.java.net Tue Oct 19 04:50:48 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 19 Oct 2021 04:50:48 GMT Subject: RFR: 8253757: Add LLVM-based backend for hsdis In-Reply-To: References: Message-ID: On Wed, 13 Oct 2021 00:00:22 GMT, Magnus Ihse Bursie wrote: > This patch expands the newly added system for hsdis backends to include LLVM. > > The actual code in hsdis-llvm.cpp is based heavily on the work by @luhenry, as published in the never integrated PR https://github.com/openjdk/jdk/pull/392. (I have basically just ripped out the binutils-based part of it.) > > Unfortunately I have not been able to make this work properly on Windows. With some additional flags I made it compile without complaints, but it caused hotspot to segfault in `LoadLibrary` (!) in `os::dll_load` when I tried to load the library. This is somewhat ironic, since the initial implementation was created by Ludovic for the very purpose of using it on Windows. > > The lack of Windows support in this patch does not mean it is impossible to get it to work, just that I need to co-operate with someone who has more experience of compiling LLVM on Windows, and/or are more eager to get this combination to work. Rather than introduce a new dependency on all of LLVM you might like to take a look at Capstone - https://www.capstone-engine.org/ . AFAIK the disassemblers are generated from the same LLVM architecture description files so the instruction coverage should be the same but the library is much more lightweight. It's packaged in most Linux distributions and there's pre-built Windows binaries available. ------------- PR: https://git.openjdk.java.net/jdk/pull/5920 From jboes at openjdk.java.net Tue Oct 19 10:22:00 2021 From: jboes at openjdk.java.net (Julia Boes) Date: Tue, 19 Oct 2021 10:22:00 GMT Subject: Integrated: 8245095: Implementation of JEP 408: Simple Web Server In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 08:52:37 GMT, Julia Boes wrote: > This change implements a simple web server that can be run on the command-line with `java -m jdk.httpserver`. > > This is facilitated by adding an entry point for the `jdk.httpserver` module, an implementation class whose main method is run when the above command is executed. This is the first such module entry point in the JDK. > > The server is a minimal HTTP server that serves the static files of a given directory, similar to existing alternatives on other platforms and convenient for testing, development, and debugging. > > Additionally, a small API is introduced for programmatic creation and customization. > > Testing: tier1-3. This pull request has now been integrated. Changeset: 9d191fce Author: Julia Boes URL: https://git.openjdk.java.net/jdk/commit/9d191fce55fa70d6a2affc724fad57b0e20e4bde Stats: 7181 lines in 42 files changed: 7146 ins; 15 del; 20 mod 8245095: Implementation of JEP 408: Simple Web Server Co-authored-by: Julia Boes Co-authored-by: Chris Hegarty Co-authored-by: Michael McMahon Co-authored-by: Daniel Fuchs Co-authored-by: Jan Lahoda Co-authored-by: Ivan ?ipka Reviewed-by: ihse, jlaskey, michaelm, chegar, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/5505 From weijun at openjdk.java.net Tue Oct 19 14:01:11 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Tue, 19 Oct 2021 14:01:11 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 Message-ID: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. ------------- Commit messages: - 8275512: Upgrade required version of jtreg to 6.1 Changes: https://git.openjdk.java.net/jdk/pull/6012/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6012&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275512 Stats: 7 lines in 6 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/6012.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6012/head:pull/6012 PR: https://git.openjdk.java.net/jdk/pull/6012 From ihse at openjdk.java.net Tue Oct 19 14:09:49 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 19 Oct 2021 14:09:49 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: <1Lt3IpTy-rZBwrcdQpbCaw1mCBR42UyLd0JIn_55qJ4=.cf17c8d5-ee9d-4ad1-8f21-ff7a4e5eeacd@github.com> On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From hannesw at openjdk.java.net Tue Oct 19 14:16:13 2021 From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 19 Oct 2021 14:16:13 GMT Subject: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI Message-ID: Please review a change to add a copy-to-clipboard feature to snippets. I took special care to make the feature usable on mobile devices. Sample output can be viewed and tested here: http://cr.openjdk.java.net/~hannesw/8275406/api.00/java.base/java/lang/Throwable.html#printStackTrace() ------------- Commit messages: - Update TestSnippetTag.java - JDK-8223357: Fine-tune alignment - JDK-8275406: Add copy-to-clipboard feature to snippet UI Changes: https://git.openjdk.java.net/jdk/pull/6011/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6011&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275406 Stats: 178 lines in 14 files changed: 166 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/6011.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6011/head:pull/6011 PR: https://git.openjdk.java.net/jdk/pull/6011 From iignatyev at openjdk.java.net Tue Oct 19 15:44:51 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 19 Oct 2021 15:44:51 GMT Subject: RFR: 8275512: Upgrade required version of jtreg to 6.1 In-Reply-To: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> References: <8ZF_bktOd9u8s06pS5q_VfPnDplwwjhlpz8pdLyHnvw=.67c1b571-5f34-4251-9872-34ccb89dbd5a@github.com> Message-ID: On Tue, 19 Oct 2021 13:51:45 GMT, Weijun Wang wrote: > As a follow up of JEP 411, we will soon disallow security manager by default. jtreg 6.1 does not set its own security manager if JDK version is >= 18. LGTM ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6012 From prappo at openjdk.java.net Tue Oct 19 16:26:53 2021 From: prappo at openjdk.java.net (Pavel Rappo) Date: Tue, 19 Oct 2021 16:26:53 GMT Subject: RFR: JDK-8275406: Add copy-to-clipboard feature to snippet UI In-Reply-To: References: Message-ID: <5NbXsri0Q2CqCIkT4rDRrXn3Jastv-sDLgzXqG5kuYI=.a280dcce-37f7-4894-b6ef-3c2ac4b7fa96@github.com> On Tue, 19 Oct 2021 13:51:03 GMT, Hannes Walln?fer wrote: > Please review a change to add a copy-to-clipboard feature to snippets. I took special care to make the feature usable on mobile devices. Sample output can be viewed and tested here: > > http://cr.openjdk.java.net/~hannesw/8275406/api.00/java.base/java/lang/Throwable.html#printStackTrace() The UI functionality looks good. Update the copyright years in `Java.gmk`, `LinkChecker.java` and maybe other files. test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java line 214: > 212: case%s() > 213:

> 214: