Re: RFR: 8342938: Problem list java/io/IO/IO.java test on Linux ppc64le
On Thu, 24 Oct 2024 09:08:09 GMT, Matthias Baesken wrote: > Test java/io/IO/IO.java fails on Linux ppc64le because of issues with > 'expect' . LGTM. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21678#pullrequestreview-2392339879
Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
On Fri, 11 Oct 2024 18:05:58 GMT, Kim Barrett wrote: >> Matthias Baesken has updated the pull request with a new target base due to >> a merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains four additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8340801 >> - move ub.h to a better location >> - remove ubsan changes from jni_md.h >> - JDK-8340801 > > Not a review, just commenting. > > I very much support the work @MBaesken has done with ubsan in HotSpot. > There's a bit of a chicken or egg problem with this kind of thing. ubsan > isn't really usable and in any way supported or supportable until the code has > been made pretty much ubsan-clean. Matthias has made substantial progress > toward that for HotSpot, and I thank him for this effort. > > There are currently four uses of the disabling attribute in HotSpot. Two are > for intentional things (writing to address zero intentionally, for testing > signal handling and the like). One is for a known issue that is being worked > on, with an associated JBS issue; the attribute is being used to reduce > testing noise in the meantime. The fourth is related to some of my recent > work (adjacent to, not caused by), and something that I think ought to be > fixed. I'll be filing a JBS issue. Along the way there have been a > substantial number of real bugs uncovered and addressed. > > My only complaint has been a tendency to be a bit too quick to reach for the > disabling attribute, without sufficient analysis and attempt to resolve in a > way that corrects the problem. Of the issues I've observed, the result of a > real fix nearly always ben a straight-up improvement. I agree with @kimbarrett in his fear that a convenience macro may lower the hurdle of just suppressing an ubsan complaint. On the other hand, using a macro makes the code look cleaner. Should there ever be a need to change how ubsan is quiesced, it can be done at one place with the use of a macro. I therefore will give the change a LGTM. - PR Comment: https://git.openjdk.org/jdk/pull/21184#issuecomment-2410653806
Re: RFR: 8340801: Disable ubsan checks in some awt/2d coding [v4]
On Wed, 9 Oct 2024 07:50:20 GMT, Matthias Baesken wrote: >> There is some old awt/2d coding where warnings occur when running with ubsan >> enabled binaries. >> However at most of these locations the coding should work (at least on our >> supported platform set) so the warnings can be disabled at least for now. >> >> The change adds a macro ATTRIBUTE_NO_UBSAN similar to what we already use >> in Hotspot coding. > > Matthias Baesken has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8340801 > - move ub.h to a better location > - remove ubsan changes from jni_md.h > - JDK-8340801 Marked as reviewed by lucy (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/21184#pullrequestreview-2366001983
Re: RFR: 8341722: Fix some warnings as errors when building on Linux with toolchain clang [v2]
On Wed, 9 Oct 2024 11:44:35 GMT, Matthias Baesken wrote: >> There are a few warnings as errors occurring when building on Linux with >> clang (clang15). Mostly these are some kind of 'unused' warnings. >> Might be related to https://bugs.openjdk.org/browse/JDK-8339156 . > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > adjust gcc warning settings; bring back rslt LGTM. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21407#pullrequestreview-2359153153
Re: RFR: 8339980: [s390x] ProblemList jdk/java/util/zip/CloseInflaterDeflaterTest.java
On Thu, 12 Sep 2024 05:12:18 GMT, Amit Kumar wrote: > This PR will ProblemList `jdk/java/util/zip/CloseInflaterDeflaterTest.java` > on s390x. This change should be reverted while fixing > [JDK-8339216](https://bugs.openjdk.org/browse/JDK-8339216). Looks good. And trivial. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20960#pullrequestreview-2312744653
Re: RFR: 8339487: ProcessHandleImpl os_getChildren sysctl call - retry in case of ENOMEM and enhance exception message [v4]
On Mon, 9 Sep 2024 07:06:22 GMT, Matthias Baesken wrote: >> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on >> macOS, a few times this error occurs : >> >> java.lang.RuntimeException: Cannot allocate memory >>at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native >> Method) >>at >> java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456) >>at >> java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434) >>at PermissionTest.childrenWithPermission(PermissionTest.java:84) >>at >> java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >>at java.base/java.lang.reflect.Method.invoke(Method.java:573) >>at >> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) >>at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) >>at >> org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) >>at >> org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) >>at >> org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) >>at >> org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) >>at >> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) >>at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) >>at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) >> >> >> Probably sysctl fails here, but it is not fully clear; it would help to >> change the exception so that the standard text is shown too in the exception >> message. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > fix typo Still looking good. - PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2289129121
Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information
On Tue, 3 Sep 2024 14:09:23 GMT, Matthias Baesken wrote: > When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS, > a few times this error occurs : > > java.lang.RuntimeException: Cannot allocate memory >at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method) >at > java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:456) >at > java.base/java.lang.ProcessHandleImpl.children(ProcessHandleImpl.java:434) >at PermissionTest.childrenWithPermission(PermissionTest.java:84) >at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >at java.base/java.lang.reflect.Method.invoke(Method.java:573) >at > org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) >at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) >at > org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) >at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) >at > org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) >at > org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) >at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) >at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) >at java.base/java.util.ArrayList.forEach(ArrayList.java:1597) > > > Probably sysctl fails here, but it is not fully clear; it would help to > change the exception so that the standard text is shown too in the exception > message. LGTM. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20839#pullrequestreview-2279640921
Re: RFR: 8330615: avoid signed integer overflows in zip_util.c readCen / hashN
On Tue, 23 Apr 2024 07:51:28 GMT, Matthias Baesken wrote: > In the hashN usages of readCen from zip_util.c we see a lot of signed integer > overflows. > For example in the java/util jtreg tests those are easily reproducable when > compiling with -ftrapv (clang/gcc toolchains). > While those overflows never seem to cause crashes or similar errors, they are > unwanted because > signed integer overflows in C cause undefined behavior. > See > https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Signed-Overflow.html >> >> For signed integers, the result of overflow in C is in principle undefined, >> meaning that anything whatsoever could happen. >> Therefore, C compilers can do optimizations that treat the overflow case >> with total unconcern. > > So we might still get unwanted results (maybe bad/strange hashing, depending > on compiler and optimization level). > > Compilation with -ftrapv causes/triggers this SIGILL on macOS showing the > issue : > # Problematic frame: > # C [libzip.dylib+0x6362] hashN+0x32 > # > > Stack: [0x7c496000,0x7c596000], sp=0x7c5957e0, free > space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [libzip.dylib+0x6362] hashN+0x32 > C [libzip.dylib+0x5d5e] readCEN+0xd2e > C [libzip.dylib+0x4ee0] ZIP_Put_In_Cache0+0x160 > V [libjvm.dylib+0x544b1e] ClassLoader::open_zip_file(char const*, char**, > JavaThread*)+0x3e > V [libjvm.dylib+0x543fec] ClassLoader::create_class_path_entry(JavaThread*, > char const*, stat const*, bool, bool)+0x6c > V [libjvm.dylib+0x543833] > ClassLoader::setup_bootstrap_search_path_impl(JavaThread*, char const*)+0xf3 > V [libjvm.dylib+0x54819b] classLoader_init1()+0x1b > V [libjvm.dylib+0x92602a] init_globals()+0x3a > V [libjvm.dylib+0x12b3b74] Threads::create_vm(JavaVMInitArgs*, bool*)+0x314 > V [libjvm.dylib+0xa848f4] JNI_CreateJavaVM+0x64 > C [libjli.dylib+0x4483] JavaMain+0x123 > C [libjli.dylib+0x7529] ThreadJavaMain+0x9 > C [libsystem_pthread.dylib+0x68fc] _pthread_start+0xe0 > C [libsystem_pthread.dylib+0x2443] thread_start+0xf LGTM. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/18908#pullrequestreview-2019585061
Re: [jdk22] RFR: 8319128: sun/security/pkcs11 tests fail on OL 7.9 aarch64
On Tue, 23 Jan 2024 10:21:42 GMT, Goetz Lindenmaier wrote: > I backport this to fix this issue in 22. We see it failing there in our CI. Looks good. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk22/pull/95#pullrequestreview-1841351221
Re: RFR: 8318705: [macos] ProblemList java/rmi/registry/multipleRegistries/MultipleRegistries.java
On Tue, 24 Oct 2023 09:51:20 GMT, Goetz Lindenmaier wrote: > …tipleRegistries.java > > The test fails in our CI with the message listed here. We see both, aarch and > x86_64. It happens rarely, but a long time back. LGTM. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16341#pullrequestreview-1694866872
Re: RFR: 8254693: Add Panama feature to pass heap segments to native code [v10]
On Fri, 20 Oct 2023 08:38:22 GMT, Jorn Vernee wrote: >> Add the ability to pass heap segments to native code. This requires using >> `Linker.Option.critical(true)` as a linker option. It has the same >> limitations as normal critical calls, namely: upcalls into Java are not >> allowed, and the native function should return relatively quickly. Heap >> segments are exposed to native code through temporary native addresses that >> are valid for the duration of the native call. >> >> The motivation for this is supporting existing Java array-based APIs that >> might have to pass multi-megabyte size arrays to native code, and are >> current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making >> a copy of the array would be overly prohibitive. >> >> Components of this patch: >> >> - New binding operator `SegmentBase`, which gets the base object of a >> `MemorySegment`. >> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether >> processing heap segments should be allowed. >> - `CallArranger` impls use new binding operators when >> `Linker.Option.critical(/* allowHeap= */ true)` is specified. >> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. >> - The object/oop + offset is exposed as temporary address to native code. >> - Since we stay in the `_thread_in_Java` state, we can safely expose the >> oops passed to the downcall stub to native code, without needing GCLocker. >> These oops are valid until we poll for safepoint, which we never do >> (invoking pure native code). >> - Only x64 and AArch64 for now. >> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on >> callbacks to get the set of source and destination registers (using >> `CallingConventionClosure`), but instead just rely on 2 equal size arrays >> with source and destination registers. This allows filtering the input java >> registers before passing them to `ArgumentShuffle`, which is required to >> filter out registers holding segment offsets. Replacing placeholder >> registers is also done as a separate pre-processing step now. See changes >> in: >> https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 >> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to >> use a common `DowncallLinker::StubGenerator`. >> - Fallback linker is also supported using JNI's >> `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` >> >> Aside: fixed existing issue with `DowncallLinker` not properly acquiring >> segments in interpreted mode. >> >> Numbers for the included benchmark on my machine are: >> >> >> Benchmar... > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > bump up argument counts in TestLargeStub to their maximum s390 part looks good now. I did not check the shared code nor the other CPU architectures. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1690103693
Re: RFR: 8254693: Add Panama feature to pass heap segments to native code [v6]
On Wed, 18 Oct 2023 17:04:52 GMT, Sidraya Jayagond wrote: >> Jorn Vernee has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - add PPC impl >> - add missing file > > Add s390x port from here > [S390x_Panama_heap_segments.txt](https://github.com/openjdk/jdk/files/13031418/S390x_Panama_heap_segments.txt) > > All tests are passing on linux S390x. One single test case is failing on Big > Endian: > test TestLayoutPaths.testBadAlignmentOfRoot(): failure. Similar to PPC Big > Endian. @sid8606 You may want to have a look at my s390 comments. - PR Comment: https://git.openjdk.org/jdk/pull/16201#issuecomment-1771020553
Re: RFR: 8254693: Add Panama feature to pass heap segments to native code [v7]
On Wed, 18 Oct 2023 17:38:24 GMT, Jorn Vernee wrote: >> Add the ability to pass heap segments to native code. This requires using >> `Linker.Option.critical(true)` as a linker option. It has the same >> limitations as normal critical calls, namely: upcalls into Java are not >> allowed, and the native function should return relatively quickly. Heap >> segments are exposed to native code through temporary native addresses that >> are valid for the duration of the native call. >> >> The motivation for this is supporting existing Java array-based APIs that >> might have to pass multi-megabyte size arrays to native code, and are >> current relying on Get-/ReleasePrimitiveArrayCritical from JNI. Where making >> a copy of the array would be overly prohibitive. >> >> Components of this patch: >> >> - New binding operator `SegmentBase`, which gets the base object of a >> `MemorySegment`. >> - Rename `UnboxAddress` to `SegmentOffset`. Add flag to specify whether >> processing heap segments should be allowed. >> - `CallArranger` impls use new binding operators when >> `Linker.Option.critical(/* allowHeap= */ true)` is specified. >> - `NativeMethodHandle`/`NativeEntryPoint` allow `Object` in their signatures. >> - The object/oop + offset is exposed as temporary address to native code. >> - Since we stay in the `_thread_in_Java` state, we can safely expose the >> oops passed to the downcall stub to native code, without needing GCLocker. >> These oops are valid until we poll for safepoint, which we never do >> (invoking pure native code). >> - Only x64 and AArch64 for now. >> - I've refactored `ArgumentShuffle` in the C++ code to no longer rely on >> callbacks to get the set of source and destination registers (using >> `CallingConventionClosure`), but instead just rely on 2 equal size arrays >> with source and destination registers. This allows filtering the input java >> registers before passing them to `ArgumentShuffle`, which is required to >> filter out registers holding segment offsets. Replacing placeholder >> registers is also done as a separate pre-processing step now. See changes >> in: >> https://github.com/openjdk/jdk/pull/16201/commits/d2b40f1117d63cc6d74e377bf88cdcf6d15ff866 >> - I've factored out `DowncallStubGenerator` in the x64 and AArch64 code to >> use a common `DowncallLinker::StubGenerator`. >> - Fallback linker is also supported using JNI's >> `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical` >> >> Aside: fixed existing issue with `DowncallLinker` not properly acquiring >> segments in interpreted mode. >> >> Numbers for the included benchmark on my machine are: >> >> >> Benchmar... > > Jorn Vernee has updated the pull request incrementally with one additional > commit since the last revision: > > add s390 support See inline comments for s390 part. I didn't review all the other code. src/hotspot/cpu/s390/downcallLinker_s390.cpp line 100: > 98: Address offset_addr(callerSP, FP_BIAS + reg_offset.offset()); > 99: __ mem2reg_opt(r_tmp1, offset_addr, true); > 100: __ z_agr(reg_oop_reg, r_tmp1); Please note that s390 is a CISC architecture. It provides instructions for almost everything. :-) Here, I would suggest to add the offset to reg_oop_reg directly from memory - without first loading the offset into a temp register (that is RISC style). It's shorter and faster: ` __ z_ag(reg_oop_reg, offset_addr);` src/hotspot/cpu/s390/downcallLinker_s390.cpp line 112: > 110: __ mem2reg_opt(r_tmp2, oop_addr, true); > 111: __ z_agr(r_tmp1, r_tmp2); > 112: __ reg2mem_opt(r_tmp1, oop_addr, true); Similar to above. You need to load only one operand into a register. __ mem2reg_opt(r_tmp2, oop_addr, true); __ z_ag(r_tmp2, offset_addr); __ reg2mem_opt(r_tmp2, oop_addr, true); - Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16201#pullrequestreview-1687765628 PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365554460 PR Review Comment: https://git.openjdk.org/jdk/pull/16201#discussion_r1365560688
Re: RFR: JDK-8315751: RandomTestBsi1999 fails often with timeouts on Linux ppc64le
On Wed, 6 Sep 2023 14:47:20 GMT, Matthias Baesken wrote: > The test RandomTestBsi1999 fails often with timeouts on Linux ppc64le; even > when it succeeds the test takes a lot of time and is close to timing out. > Probably we should increase the timeout value for this test. Looks good. - PR Review: https://git.openjdk.org/jdk/pull/15594#pullrequestreview-1614961811
Re: RFR: JDK-8314121: test tools/jpackage/share/RuntimePackageTest.java#id0 fails on RHEL8
On Fri, 1 Sep 2023 07:22:12 GMT, Matthias Baesken wrote: > on some RHEL Linux 8.X machines , we run into errors in test > tools/jpackage/share/RuntimePackageTest.java#id0 , error can be seen below. > It looks like these errors occur when running the jtreg tests with higher > concurrency, I did not see them when running just the single test. > > When adding some test output , we see the 2 top install dirs below (1 is > expected, not 2) : > ./test/unpacked-rpm/opt > ./test/unpacked-rpm/usr > > error output : > > java.lang.AssertionError: Expected [1]. Actual [2]: Check the package has 1 > top installation directories >at jdk.jpackage.test.TKit.error(TKit.java:273) >at jdk.jpackage.test.TKit.assertEquals(TKit.java:576) >at > jdk.jpackage.test.PackageTest$Handler.verifyRootCountInUnpackedPackage(PackageTest.java:705) >at > jdk.jpackage.test.PackageTest$Handler.lambda$verifyPackageInstalled$3(PackageTest.java:635) >at java.base/java.util.Optional.ifPresent(Optional.java:178) >at > jdk.jpackage.test.PackageTest$Handler.verifyPackageInstalled(PackageTest.java:633) >at jdk.jpackage.test.PackageTest$Handler.accept(PackageTest.java:592) >at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:504) >at jdk.jpackage.test.PackageTest$2.accept(PackageTest.java:411) >at > jdk.jpackage.test.Functional$ThrowingConsumer.lambda$toConsumer$0(Functional.java:41) >at java.base/java.lang.Iterable.forEach(Iterable.java:75) >at > jdk.jpackage.test.PackageTest.lambda$runActions$24(PackageTest.java:381) >at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >at > jdk.jpackage.test.PackageTest.lambda$runActions$25(PackageTest.java:380) >at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) >at jdk.jpackage.test.PackageTest.runActions(PackageTest.java:379) >at > jdk.jpackage.test.RunnablePackageTest.run(RunnablePackageTest.java:58) >at RuntimePackageTest.test(RuntimePackageTest.java:83) >at > java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) >at java.base/java.lang.reflect.Method.invoke(Method.java:580) >at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145) >at jdk.jpackage.test.TestInstance.run(TestInstance.java:230) >at jdk.jpackage.test.TKit.lambda$ignoreExceptions$5(TKit.java:141) >at jdk.jpackage.test.TKit.lambda$runTests$3(TKit.java:126) >at > java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1708) >at java.base/jav... LGTM. Thanks for fixing. The add'l output doesn't fix anything, but may be helpful in the future. - Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/15528#pullrequestreview-1610495096
Re: RFR: JDK-8310380: Handle problems in core-related tests on macOS when codesign tool does not work
On Tue, 20 Jun 2023 13:23:16 GMT, Matthias Baesken wrote:
> Currently, a number of tests fail on macOS because they miss the core file
> (e.g. serviceability/sa/TestJmapCore.java).
> The reason is that configure detects on some setups that codesign does not
> work ("checking if debug mode codesign is possible... no) .
> So adding the needed entitlement to generate cores is not done in the build.
> This is currently not checked later in the tests.
> But without the entitlement, a core is not generated.
LGTM.
Thanks for enhancing test analysis.
-
Marked as reviewed by lucy (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/14562#pullrequestreview-1491050558
Re: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10]
On Wed, 12 Apr 2023 03:44:45 GMT, Amit Kumar wrote: > Another remark: Old JDK on s390 used "os.arch = zArch_64", current one > "os.arch = s390x". @offamitkumar: You probably want to take a look. zArch_64 is not relevant/not used in the OpenJDK port to IBM System z. As noted elsewhere in the PR, it's the architecture name that was used in the initial, proprietary port by SAP. I found just one occurrence of the string in the head revision, and that was in test/lib/jdk/test/lib/Platform.java. - PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505110504
Re: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7]
On Fri, 7 Apr 2023 11:21:33 GMT, Thomas Stuefe wrote: >> Hello Thomas, that change was based on the review comment here >> https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942 > > Okay, Lutz is the expert here. Sorry for the noise. Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore). s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example. - PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160657249
Re: RFR: JDK-8293659: Improve UnsatisfiedLinkError error message to include dlopen error details [v2]
On Fri, 16 Sep 2022 07:27:44 GMT, Matthias Baesken wrote: >> When trying to load a x64 lib on macOS aarch64 one got previously this >> detailed message before >> [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703): >> >> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib: >> dlopen(/testing/jco3/macOsx64/libsapjco3.dylib, 1): no suitable image found. >> Did find: > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust throwExceptionIfFail Changes look good to me. - Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.org/jdk/pull/10286
