From magnus.ihse.bursie at oracle.com Mon Aug 10 12:52:13 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 10 Aug 2020 14:52:13 +0200 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> Message-ID: <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> On 2020-07-28 19:20, Aleksei Voitylov wrote: > Hi Mikael, > > thank you for looking into it. Here is an updated version of the webrev > with your comments addressed: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ Some build comments: make/autoconf/build-aux/config.sub: I think you could match on just "linux-musl", to facilitate future ports to other architectures. make/autoconf/platform.m4: The new clib matching should move to a separate PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have been named "FOR" instead of "FROM"...) Apart from this, it looks good from a build perspective. /Magnus > > Please see inline for details. > > On 08/07/2020 21:52, Mikael Vidstedt wrote: >>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov wrote: >>> >>> Hi, >>> >>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>> patch [2] before moving the JEP to PTT and submitting for review >>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor cleanup >>> of the changes from the original portola branch [3] was made. >>> >>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >> So glad to see that this is making progress, thanks a lot for picking it up! I?ve had a quick look at the changes and have a few initial comments, inlined below. I?ll also mention that I recently started the work of bringing the portola repo up-to-date again after the move to GitHub earlier this year. You?ll see that some of the changes I?m making there are not the same as the ones you have in this patch. Don?t read anything into that please - I started making those changes before I realized that you had this patch out for review and it wouldn?t surprise me if your version is preferable in many/most cases. Let?s figure out how to resolve that in the portola repo a bit later. >> >> Disclaimer: this is *not* a complete review, and should not be considered as blessing the changes for upstream/mainline. For that you?ll need to get the changes sent out to the respective lists (build-dev, hotspot-dev, ?). >> >> High level comment: There are a handful of JBS issues with Fix Version=repo-portola which would probably be good to have a look at and possibly close if they?re no longer relevant. >> > I did some bug scrubbing, here is the list of open issues: > > JDK-8241092 make test-bundles fails on Alpine Linux because of > TestTLS.java test > ? is fixed as part of the proposed patch. > JDK-8240187 Test > hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java > fails on Alpine Linux > ? the test is excluded as part of the proposed patch. > JDK-8241053 Hotspot > runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test > fails on Alpine Linux with debug build > ? - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java > ? - runtime/Thread/TestThreadStackSizes.java > ? tests are fixed as part of the proposed patch, David suggests to fix > it in mainline as it does not seem to be specific to the port. I tend to > agree with the evaluation. > JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH > ? please see below > JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine Linux > ? - test/jdk/com/sun/jdi/JdwpAllowTest.java > ? - test/jdk/com/sun/jdi/JdwpListenTest.java > ? Alex is looking into the reason of the issue. It could be because of > the network settings on the host or the way the getaddrinfo(3) returns > addresses in musl. Currently it looks to be not very specific to the > port, though. > > These issues reflect the current testing status of the port. >>> Build System, Toolchains: >>> >>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>> -f1" construct with sed to be slightly more robust >>> - make/autoconf/build-aux/config.sub - style brought in line with the >>> current file style >>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>> after JDK-8239450 [4] >>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC warnings >>> and modifying initialization is no longer required, Alpine Linux >>> toolchain is quite recent >> Great cleanups! Happy to see that the SA special casing is no longer needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to thank for that. >> >> * ReleaseFile.gmk >> >> The choice to use ?LIBC? as the key name in the releases file was not something I/we spent a lot of time on, so we?ll want to revisit that and make sure it?s the right name or come up with a better one. > For ReleaseFile.gmk I think LIBC is good, as it is used as a handle for > the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what came > up as the least intrusive indication that musl is a kind of libc. > Leaving it just as MUSL could be confusing. >>> Desktop: >>> >>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - changes are >>> present upstream and no longer required >> Yay! >> >>> HotSpot: >>> >>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available logic >>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>> strerror is cleaner and more portable, the code originally present there >>> is not thread-safe so it's ok to use it >>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a header >>> instead >> * os_linux.cpp >> >> Out of curiosity, have you tested with/without the various libnuma library versions? > Please see the updated version of the patch which is tested to work with > (and without) libnuma v1.2 on Alpine Linux. Note that musl can't > recognize library versions, and it only allows to install v1.2 in the > distribution. It's good there is a single place where a change was > required. >> set_glibc_version -> set_libc_version? > Fixed, thanks. >> * globalDefinitions_gcc.hpp >> >> Did you verify that the change to use isnan instead of isnanf is correct for all versions of linux/bsd and the respective (supported) toolchain versions? See: https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the JEP in JBS. > I updated JDK-8178689 with proof that such a replacement is safe for all > practical combinations of gcc/glibc and llvm versions. >> * ps_proc.c >> >> Hm.. What makes you say that the original code is not thread-safe? > I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by > corresponding syncronized constructs. > > That's because nobody claims that ptrace_attach is thread-safe or > re-enterant. It depends to kernel implementation and attempt to use it > from multiple threads could lead to completely unpredictable results. If > we run ptrace_attach from different threads but with the same PID, it > either crash the target process or fail. And it doesn't have any sense > from serviceability agent point of view. > > Running ptrace_attach from multiple threads with different PIDs should > be more or less OK - I trust modern kernel, but I don't see any usecase > or command line support for using hotspot agent with multiple pids. > > So using strerror instead of strerror_r to mitigate compatibility issues > should not be a problem. >>> java.base: >>> >>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX - 2) >>> a define >>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip this >>> for now. Also, if the OS does not handle scripts without shebang it >>> should not be emulated. >> * jdk_util_md.h >> >> The same isnan comment as above. > This is no longer relevant, fixed upstream. >> * INTERRUPT_SIGNAL >> >> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better name) be moved to something like net_util_md.h so that it is shared for both files using it? I?d also remove the spaces around the arguments to pthread_kill in linux_close.c (pre-existing). > Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >> * java_md.c >> >> Did you look into alternatives ways to resolve the issue? As covered by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we could find some other way of dealing with that to avoid the the LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. > Yes, but neither of them looked better [1, 2]. >> * childproc.c >> >> Remind me: what happens without the fix? I?m thinking there was some reason I made it to start with..? > Without the fix we rely on the OS execve mechanism. On Alpine it does > not currently handle files without shebang [3]. >>> Tests: >>> >>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>> - added WB_InternalVMInfo method to hotspot/share/prims/whitebox.cpp for >>> better test handling >>> - refactored affected tests to cater for the above >> * VMProps.java >> >> If I read it correctly I think WB.internalVMInfo().contains("musl?) may incorrectly return true if the VM info strings happens to contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll probably want something more targeted for the check. Also, the pattern used in other places in the file to convert the boolean to a String seems to be ?" + p. > Yes, converted the check into > WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be > more robust. >> * exeinvoke.c >> >> I?m don?t know the "complicated interaction of signal handlers? well enough to understand if the changes are correct, but assuming they are: >> >> I?d feel better having the whole JDK1_1InitArgs jdk_args struct initialized (memset). >> >> size_t stacksize seems to be unused. Perhaps get_java_stacksize should return a size_t? >> >> I?d also remove the spaces between pthread_ and the argument list while your at it (also pre-existing), not exactly obvious why only the pthread_ calls have them.. > This is addressed in the updated webrev. >> * exestack-tls.c >> >> As a potential alternative, base the decision on a define set by the build system (MUSL_LIBC). Just something to consider. What you have should work. > I'd suggest to keep it as is - there is no other precedent of this in > tests to support altering the build system. >> * TestTerminatedThread.java >> >> I don?t know where we stand on adding comments, but personally I?d prefer a comment explaining why the test is excluded when running with musl (not unlike the one you have in NativeLibraryTest.java). > Fixed in the updated webrev. >> * Test7029048.java >> >> Can VMProps::isMusl be reused? I?m assuming that moving the predicate definition to TestHelper would require a slew of tests to use -XX:+WhiteBox? > Yes, this is exactly the problem we try to avoid here. Another option is > to introduce another helper class just for these couple of tests, but > there would be only a couple of places where it would be used. >> Also, I know I looked at this before but don?t remember the conclusion: why is the check at the end ?passed < expected? rather than exact match - passed == expected? (pre-existing) > The test was refactored upstream and does not have any magic numbers any > more [4]. The webrev is updated. >> Finally a question: What level of testing have you done of this and on which versions of Alpine/?? > JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, > Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no > regressions. A downport of these changes to 14 passes JCK 14 on these > platforms. > > The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. With > the exception of the issues listed above and SA which is not supported > as per the JEP, there are no differences with Linux x86_64. A downport > of these changes to 14 passes JCK 14 on Alpine Linux. > > -Aleksei > > [1] https://www.openwall.com/lists/musl/2020/05/28/5 > [2] https://www.openwall.com/lists/musl/2020/05/25/3 > [3] https://www.openwall.com/lists/musl/2020/02/12/9 > [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >> Cheers, >> Mikael >> >>> Thanks, >>> -Aleksei >>> >>> [1] https://openjdk.java.net/jeps/386 >>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 >>> >>> From aleksei.voitylov at bell-sw.com Wed Aug 12 16:58:08 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 12 Aug 2020 19:58:08 +0300 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> Message-ID: <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> Hi Magnus, thank you for looking into it. Here is a webrev that addresses your comments: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ As far as code changes are concerned, I'd still like to seek consensus within this project if the patch is overall good and has reached a point to submit for pre-review upstream. Meanwhile, it was concluded that JDK-8250630 is a generic issue that will be submitted upstream separately - it has to do with linux networking stack configuration. -Aleksei On 10/08/2020 15:52, Magnus Ihse Bursie wrote: > On 2020-07-28 19:20, Aleksei Voitylov wrote: >> Hi Mikael, >> >> thank you for looking into it. Here is an updated version of the webrev >> with your comments addressed: >> >> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ > Some build comments: > > make/autoconf/build-aux/config.sub: > I think you could match on just "linux-musl", to facilitate future > ports to other architectures. > > make/autoconf/platform.m4: > The new clib matching should move to a separate > PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have > been named "FOR" instead of "FROM"...) > > Apart from this, it looks good from a build perspective. > > /Magnus >> >> Please see inline for details. >> >> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>> wrote: >>>> >>>> Hi, >>>> >>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>> patch [2] before moving the JEP to PTT and submitting for review >>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor cleanup >>>> of the changes from the original portola branch [3] was made. >>>> >>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>> So glad to see that this is making progress, thanks a lot for >>> picking it up! I?ve had a quick look at the changes and have a few >>> initial comments, inlined below. I?ll also mention that I recently >>> started the work of bringing the portola repo up-to-date again after >>> the move to GitHub earlier this year. You?ll see that some of the >>> changes I?m making there are not the same as the ones you have in >>> this patch. Don?t read anything into that please - I started making >>> those changes before I realized that you had this patch out for >>> review and it wouldn?t surprise me if your version is preferable in >>> many/most cases. Let?s figure out how to resolve that in the portola >>> repo a bit later. >>> >>> Disclaimer: this is *not* a complete review, and should not be >>> considered as blessing the changes for upstream/mainline. For that >>> you?ll need to get the changes sent out to the respective lists >>> (build-dev, hotspot-dev, ?). >>> >>> High level comment: There are a handful of JBS issues with Fix >>> Version=repo-portola which would probably be good to have a look at >>> and possibly close if they?re no longer relevant. >>> >> I did some bug scrubbing, here is the list of open issues: >> >> JDK-8241092 make test-bundles fails on Alpine Linux because of >> TestTLS.java test >> ?? is fixed as part of the proposed patch. >> JDK-8240187 Test >> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >> fails on Alpine Linux >> ?? the test is excluded as part of the proposed patch. >> JDK-8241053 Hotspot >> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >> fails on Alpine Linux with debug build >> ?? - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >> ?? - runtime/Thread/TestThreadStackSizes.java >> ?? tests are fixed as part of the proposed patch, David suggests to fix >> it in mainline as it does not seem to be specific to the port. I tend to >> agree with the evaluation. >> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >> ?? please see below >> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >> Linux >> ?? - test/jdk/com/sun/jdi/JdwpAllowTest.java >> ?? - test/jdk/com/sun/jdi/JdwpListenTest.java >> ?? Alex is looking into the reason of the issue. It could be because of >> the network settings on the host or the way the getaddrinfo(3) returns >> addresses in musl. Currently it looks to be not very specific to the >> port, though. >> >> These issues reflect the current testing status of the port. >>>> Build System, Toolchains: >>>> >>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>>> -f1" construct with sed to be slightly more robust >>>> - make/autoconf/build-aux/config.sub - style brought in line with the >>>> current file style >>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>> after JDK-8239450 [4] >>>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC warnings >>>> and modifying initialization is no longer required, Alpine Linux >>>> toolchain is quite recent >>> Great cleanups! Happy to see that the SA special casing is no longer >>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>> thank for that. >>> >>> * ReleaseFile.gmk >>> >>> The choice to use ?LIBC? as the key name in the releases file was >>> not something I/we spent a lot of time on, so we?ll want to revisit >>> that and make sure it?s the right name or come up with a better one. >> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle for >> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what came >> up as the least intrusive indication that musl is a kind of libc. >> Leaving it just as MUSL could be confusing. >>>> Desktop: >>>> >>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>> changes are >>>> present upstream and no longer required >>> Yay! >>> >>>> HotSpot: >>>> >>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>> logic >>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>> strerror is cleaner and more portable, the code originally present >>>> there >>>> is not thread-safe so it's ok to use it >>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a header >>>> instead >>> * os_linux.cpp >>> >>> Out of curiosity, have you tested with/without the various libnuma >>> library versions? >> Please see the updated version of the patch which is tested to work with >> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >> recognize library versions, and it only allows to install v1.2 in the >> distribution. It's good there is a single place where a change was >> required. >>> set_glibc_version -> set_libc_version? >> Fixed, thanks. >>> * globalDefinitions_gcc.hpp >>> >>> Did you verify that the change to use isnan instead of isnanf is >>> correct for all versions of linux/bsd and the respective (supported) >>> toolchain versions? See:? >>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>> JEP in JBS. >> I updated JDK-8178689 with proof that such a replacement is safe for all >> practical combinations of gcc/glibc and llvm versions. >>> * ps_proc.c >>> >>> Hm.. What makes you say that the original code is not thread-safe? >> I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by >> corresponding syncronized constructs. >> >> That's because nobody claims that ptrace_attach is thread-safe or >> re-enterant. It depends to kernel implementation and attempt to use it >> from multiple threads could lead to completely unpredictable results. If >> we run ptrace_attach from different threads but with the same PID, it >> either crash the target process or fail. And it doesn't have any sense >> from serviceability agent point of view. >> >> Running ptrace_attach from multiple threads with different PIDs should >> be more or less OK - I trust modern kernel, but I don't see any usecase >> or command line support for using hotspot agent with multiple pids. >> >> So using strerror instead of strerror_r to mitigate compatibility issues >> should not be a problem. >>>> java.base: >>>> >>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>> - 2) >>>> a define >>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip this >>>> for now. Also, if the OS does not handle scripts without shebang it >>>> should not be emulated. >>> * jdk_util_md.h >>> >>> The same isnan comment as above. >> This is no longer relevant, fixed upstream. >>> * INTERRUPT_SIGNAL >>> >>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>> name) be moved to something like net_util_md.h so that it is shared >>> for both files using it? I?d also remove the spaces around the >>> arguments to pthread_kill in linux_close.c (pre-existing). >> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>> * java_md.c >>> >>> Did you look into alternatives ways to resolve the issue? As covered >>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>> could find some other way of dealing with that to avoid the the >>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >> Yes, but neither of them looked better [1, 2]. >>> * childproc.c >>> >>> Remind me: what happens without the fix? I?m thinking there was some >>> reason I made it to start with..? >> Without the fix we rely on the OS execve mechanism. On Alpine it does >> not currently handle files without shebang [3]. >>>> Tests: >>>> >>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>> - added WB_InternalVMInfo method to >>>> hotspot/share/prims/whitebox.cpp for >>>> better test handling >>>> - refactored affected tests to cater for the above >>> * VMProps.java >>> >>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>> may incorrectly return true if the VM info strings happens to >>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>> probably want something more targeted for the check. Also, the >>> pattern used in other places in the file to convert the boolean to a >>> String seems to be ?" + p. >> Yes, converted the check into >> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be >> more robust. >>> * exeinvoke.c >>> >>> I?m don?t know the "complicated interaction of signal handlers? well >>> enough to understand if the changes are correct, but assuming they are: >>> >>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>> initialized (memset). >>> >>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>> should return a size_t? >>> >>> I?d also remove the spaces between pthread_ and the argument list >>> while your at it (also pre-existing), not exactly obvious why only >>> the pthread_ calls have them.. >> This is addressed in the updated webrev. >>> * exestack-tls.c >>> >>> As a potential alternative, base the decision on a define set by the >>> build system (MUSL_LIBC). Just something to consider. What you have >>> should work. >> I'd suggest to keep it as is - there is no other precedent of this in >> tests to support altering the build system. >>> * TestTerminatedThread.java >>> >>> I don?t know where we stand on adding comments, but personally I?d >>> prefer a comment explaining why the test is excluded when running >>> with musl (not unlike the one you have in NativeLibraryTest.java). >> Fixed in the updated webrev. >>> * Test7029048.java >>> >>> Can VMProps::isMusl be reused? I?m assuming that moving the >>> predicate definition to TestHelper would require a slew of tests to >>> use -XX:+WhiteBox? >> Yes, this is exactly the problem we try to avoid here. Another option is >> to introduce another helper class just for these couple of tests, but >> there would be only a couple of places where it would be used. >>> Also, I know I looked at this before but don?t remember the >>> conclusion: why is the check at the end ?passed < expected? rather >>> than exact match - passed == expected? (pre-existing) >> The test was refactored upstream and does not have any magic numbers any >> more [4]. The webrev is updated. >>> Finally a question: What level of testing have you done of this and >>> on which versions of Alpine/?? >> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, >> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >> regressions. A downport of these changes to 14 passes JCK 14 on these >> platforms. >> >> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. With >> the exception of the issues listed above and SA which is not supported >> as per the JEP, there are no differences with Linux x86_64. A downport >> of these changes to 14 passes JCK 14 on Alpine Linux. >> >> -Aleksei >> >> [1] https://www.openwall.com/lists/musl/2020/05/28/5 >> [2] https://www.openwall.com/lists/musl/2020/05/25/3 >> [3] https://www.openwall.com/lists/musl/2020/02/12/9 >> [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>> Cheers, >>> Mikael >>> >>>> Thanks, >>>> -Aleksei >>>> >>>> [1] https://openjdk.java.net/jeps/386 >>>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 >>>> >>>> > From magnus.ihse.bursie at oracle.com Thu Aug 13 10:05:55 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 13 Aug 2020 12:05:55 +0200 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> Message-ID: <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> On 2020-08-12 18:58, Aleksei Voitylov wrote: > Hi Magnus, > > thank you for looking into it. Here is a webrev that addresses your > comments: > > http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ Thank you, looks much better! (If I may ask of anything more, it is to keep a consistent ordering OS -> CPU -> LIBC? where they all occur together. It helps keep your sanity up when reading the code) /Magnus > > As far as code changes are concerned, I'd still like to seek consensus > within this project if the patch is overall good and has reached a point > to submit for pre-review upstream. Meanwhile, it was concluded that > JDK-8250630 is a generic issue that will be submitted upstream > separately - it has to do with linux networking stack configuration. > > -Aleksei > > On 10/08/2020 15:52, Magnus Ihse Bursie wrote: >> On 2020-07-28 19:20, Aleksei Voitylov wrote: >>> Hi Mikael, >>> >>> thank you for looking into it. Here is an updated version of the webrev >>> with your comments addressed: >>> >>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ >> Some build comments: >> >> make/autoconf/build-aux/config.sub: >> I think you could match on just "linux-musl", to facilitate future >> ports to other architectures. >> >> make/autoconf/platform.m4: >> The new clib matching should move to a separate >> PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have >> been named "FOR" instead of "FROM"...) >> >> Apart from this, it looks good from a build perspective. >> >> /Magnus >>> Please see inline for details. >>> >>> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>>> patch [2] before moving the JEP to PTT and submitting for review >>>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor cleanup >>>>> of the changes from the original portola branch [3] was made. >>>>> >>>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>> So glad to see that this is making progress, thanks a lot for >>>> picking it up! I?ve had a quick look at the changes and have a few >>>> initial comments, inlined below. I?ll also mention that I recently >>>> started the work of bringing the portola repo up-to-date again after >>>> the move to GitHub earlier this year. You?ll see that some of the >>>> changes I?m making there are not the same as the ones you have in >>>> this patch. Don?t read anything into that please - I started making >>>> those changes before I realized that you had this patch out for >>>> review and it wouldn?t surprise me if your version is preferable in >>>> many/most cases. Let?s figure out how to resolve that in the portola >>>> repo a bit later. >>>> >>>> Disclaimer: this is *not* a complete review, and should not be >>>> considered as blessing the changes for upstream/mainline. For that >>>> you?ll need to get the changes sent out to the respective lists >>>> (build-dev, hotspot-dev, ?). >>>> >>>> High level comment: There are a handful of JBS issues with Fix >>>> Version=repo-portola which would probably be good to have a look at >>>> and possibly close if they?re no longer relevant. >>>> >>> I did some bug scrubbing, here is the list of open issues: >>> >>> JDK-8241092 make test-bundles fails on Alpine Linux because of >>> TestTLS.java test >>> ?? is fixed as part of the proposed patch. >>> JDK-8240187 Test >>> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >>> fails on Alpine Linux >>> ?? the test is excluded as part of the proposed patch. >>> JDK-8241053 Hotspot >>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >>> fails on Alpine Linux with debug build >>> ?? - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>> ?? - runtime/Thread/TestThreadStackSizes.java >>> ?? tests are fixed as part of the proposed patch, David suggests to fix >>> it in mainline as it does not seem to be specific to the port. I tend to >>> agree with the evaluation. >>> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >>> ?? please see below >>> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >>> Linux >>> ?? - test/jdk/com/sun/jdi/JdwpAllowTest.java >>> ?? - test/jdk/com/sun/jdi/JdwpListenTest.java >>> ?? Alex is looking into the reason of the issue. It could be because of >>> the network settings on the host or the way the getaddrinfo(3) returns >>> addresses in musl. Currently it looks to be not very specific to the >>> port, though. >>> >>> These issues reflect the current testing status of the port. >>>>> Build System, Toolchains: >>>>> >>>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>>>> -f1" construct with sed to be slightly more robust >>>>> - make/autoconf/build-aux/config.sub - style brought in line with the >>>>> current file style >>>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>>> after JDK-8239450 [4] >>>>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC warnings >>>>> and modifying initialization is no longer required, Alpine Linux >>>>> toolchain is quite recent >>>> Great cleanups! Happy to see that the SA special casing is no longer >>>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>>> thank for that. >>>> >>>> * ReleaseFile.gmk >>>> >>>> The choice to use ?LIBC? as the key name in the releases file was >>>> not something I/we spent a lot of time on, so we?ll want to revisit >>>> that and make sure it?s the right name or come up with a better one. >>> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle for >>> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what came >>> up as the least intrusive indication that musl is a kind of libc. >>> Leaving it just as MUSL could be confusing. >>>>> Desktop: >>>>> >>>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>>> changes are >>>>> present upstream and no longer required >>>> Yay! >>>> >>>>> HotSpot: >>>>> >>>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>>> logic >>>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>>> strerror is cleaner and more portable, the code originally present >>>>> there >>>>> is not thread-safe so it's ok to use it >>>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a header >>>>> instead >>>> * os_linux.cpp >>>> >>>> Out of curiosity, have you tested with/without the various libnuma >>>> library versions? >>> Please see the updated version of the patch which is tested to work with >>> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >>> recognize library versions, and it only allows to install v1.2 in the >>> distribution. It's good there is a single place where a change was >>> required. >>>> set_glibc_version -> set_libc_version? >>> Fixed, thanks. >>>> * globalDefinitions_gcc.hpp >>>> >>>> Did you verify that the change to use isnan instead of isnanf is >>>> correct for all versions of linux/bsd and the respective (supported) >>>> toolchain versions? See: >>>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>>> JEP in JBS. >>> I updated JDK-8178689 with proof that such a replacement is safe for all >>> practical combinations of gcc/glibc and llvm versions. >>>> * ps_proc.c >>>> >>>> Hm.. What makes you say that the original code is not thread-safe? >>> I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by >>> corresponding syncronized constructs. >>> >>> That's because nobody claims that ptrace_attach is thread-safe or >>> re-enterant. It depends to kernel implementation and attempt to use it >>> from multiple threads could lead to completely unpredictable results. If >>> we run ptrace_attach from different threads but with the same PID, it >>> either crash the target process or fail. And it doesn't have any sense >>> from serviceability agent point of view. >>> >>> Running ptrace_attach from multiple threads with different PIDs should >>> be more or less OK - I trust modern kernel, but I don't see any usecase >>> or command line support for using hotspot agent with multiple pids. >>> >>> So using strerror instead of strerror_r to mitigate compatibility issues >>> should not be a problem. >>>>> java.base: >>>>> >>>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>>> - 2) >>>>> a define >>>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip this >>>>> for now. Also, if the OS does not handle scripts without shebang it >>>>> should not be emulated. >>>> * jdk_util_md.h >>>> >>>> The same isnan comment as above. >>> This is no longer relevant, fixed upstream. >>>> * INTERRUPT_SIGNAL >>>> >>>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>>> name) be moved to something like net_util_md.h so that it is shared >>>> for both files using it? I?d also remove the spaces around the >>>> arguments to pthread_kill in linux_close.c (pre-existing). >>> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>>> * java_md.c >>>> >>>> Did you look into alternatives ways to resolve the issue? As covered >>>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>>> could find some other way of dealing with that to avoid the the >>>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >>> Yes, but neither of them looked better [1, 2]. >>>> * childproc.c >>>> >>>> Remind me: what happens without the fix? I?m thinking there was some >>>> reason I made it to start with..? >>> Without the fix we rely on the OS execve mechanism. On Alpine it does >>> not currently handle files without shebang [3]. >>>>> Tests: >>>>> >>>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>>> - added WB_InternalVMInfo method to >>>>> hotspot/share/prims/whitebox.cpp for >>>>> better test handling >>>>> - refactored affected tests to cater for the above >>>> * VMProps.java >>>> >>>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>>> may incorrectly return true if the VM info strings happens to >>>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>>> probably want something more targeted for the check. Also, the >>>> pattern used in other places in the file to convert the boolean to a >>>> String seems to be ?" + p. >>> Yes, converted the check into >>> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be >>> more robust. >>>> * exeinvoke.c >>>> >>>> I?m don?t know the "complicated interaction of signal handlers? well >>>> enough to understand if the changes are correct, but assuming they are: >>>> >>>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>>> initialized (memset). >>>> >>>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>>> should return a size_t? >>>> >>>> I?d also remove the spaces between pthread_ and the argument list >>>> while your at it (also pre-existing), not exactly obvious why only >>>> the pthread_ calls have them.. >>> This is addressed in the updated webrev. >>>> * exestack-tls.c >>>> >>>> As a potential alternative, base the decision on a define set by the >>>> build system (MUSL_LIBC). Just something to consider. What you have >>>> should work. >>> I'd suggest to keep it as is - there is no other precedent of this in >>> tests to support altering the build system. >>>> * TestTerminatedThread.java >>>> >>>> I don?t know where we stand on adding comments, but personally I?d >>>> prefer a comment explaining why the test is excluded when running >>>> with musl (not unlike the one you have in NativeLibraryTest.java). >>> Fixed in the updated webrev. >>>> * Test7029048.java >>>> >>>> Can VMProps::isMusl be reused? I?m assuming that moving the >>>> predicate definition to TestHelper would require a slew of tests to >>>> use -XX:+WhiteBox? >>> Yes, this is exactly the problem we try to avoid here. Another option is >>> to introduce another helper class just for these couple of tests, but >>> there would be only a couple of places where it would be used. >>>> Also, I know I looked at this before but don?t remember the >>>> conclusion: why is the check at the end ?passed < expected? rather >>>> than exact match - passed == expected? (pre-existing) >>> The test was refactored upstream and does not have any magic numbers any >>> more [4]. The webrev is updated. >>>> Finally a question: What level of testing have you done of this and >>>> on which versions of Alpine/?? >>> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux Arm, >>> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >>> regressions. A downport of these changes to 14 passes JCK 14 on these >>> platforms. >>> >>> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. With >>> the exception of the issues listed above and SA which is not supported >>> as per the JEP, there are no differences with Linux x86_64. A downport >>> of these changes to 14 passes JCK 14 on Alpine Linux. >>> >>> -Aleksei >>> >>> [1] https://www.openwall.com/lists/musl/2020/05/28/5 >>> [2] https://www.openwall.com/lists/musl/2020/05/25/3 >>> [3] https://www.openwall.com/lists/musl/2020/02/12/9 >>> [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>>> Cheers, >>>> Mikael >>>> >>>>> Thanks, >>>>> -Aleksei >>>>> >>>>> [1] https://openjdk.java.net/jeps/386 >>>>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>>>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 >>>>> >>>>> From aleksei.voitylov at bell-sw.com Thu Aug 13 13:59:08 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 13 Aug 2020 16:59:08 +0300 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> Message-ID: <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> Hi Magnus, you are right: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.03/ -Aleksei On 13/08/2020 13:05, Magnus Ihse Bursie wrote: > On 2020-08-12 18:58, Aleksei Voitylov wrote: >> Hi Magnus, >> >> thank you for looking into it. Here is a webrev that addresses your >> comments: >> >> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ > Thank you, looks much better! (If I may ask of anything more, it is to > keep a consistent ordering OS -> CPU -> LIBC? where they all occur > together. It helps keep your sanity up when reading the code) > > /Magnus > >> >> As far as code changes are concerned, I'd still like to seek consensus >> within this project if the patch is overall good and has reached a point >> to submit for pre-review upstream. Meanwhile, it was concluded that >> JDK-8250630 is a generic issue that will be submitted upstream >> separately - it has to do with linux networking stack configuration. >> >> -Aleksei >> >> On 10/08/2020 15:52, Magnus Ihse Bursie wrote: >>> On 2020-07-28 19:20, Aleksei Voitylov wrote: >>>> Hi Mikael, >>>> >>>> thank you for looking into it. Here is an updated version of the >>>> webrev >>>> with your comments addressed: >>>> >>>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ >>> Some build comments: >>> >>> make/autoconf/build-aux/config.sub: >>> I think you could match on just "linux-musl", to facilitate future >>> ports to other architectures. >>> >>> make/autoconf/platform.m4: >>> The new clib matching should move to a separate >>> PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have >>> been named "FOR" instead of "FROM"...) >>> >>> Apart from this, it looks good from a build perspective. >>> >>> /Magnus >>>> Please see inline for details. >>>> >>>> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>>>> patch [2] before moving the JEP to PTT and submitting for review >>>>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor >>>>>> cleanup >>>>>> of the changes from the original portola branch [3] was made. >>>>>> >>>>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>> So glad to see that this is making progress, thanks a lot for >>>>> picking it up! I?ve had a quick look at the changes and have a few >>>>> initial comments, inlined below. I?ll also mention that I recently >>>>> started the work of bringing the portola repo up-to-date again after >>>>> the move to GitHub earlier this year. You?ll see that some of the >>>>> changes I?m making there are not the same as the ones you have in >>>>> this patch. Don?t read anything into that please - I started making >>>>> those changes before I realized that you had this patch out for >>>>> review and it wouldn?t surprise me if your version is preferable in >>>>> many/most cases. Let?s figure out how to resolve that in the portola >>>>> repo a bit later. >>>>> >>>>> Disclaimer: this is *not* a complete review, and should not be >>>>> considered as blessing the changes for upstream/mainline. For that >>>>> you?ll need to get the changes sent out to the respective lists >>>>> (build-dev, hotspot-dev, ?). >>>>> >>>>> High level comment: There are a handful of JBS issues with Fix >>>>> Version=repo-portola which would probably be good to have a look at >>>>> and possibly close if they?re no longer relevant. >>>>> >>>> I did some bug scrubbing, here is the list of open issues: >>>> >>>> JDK-8241092 make test-bundles fails on Alpine Linux because of >>>> TestTLS.java test >>>> ??? is fixed as part of the proposed patch. >>>> JDK-8240187 Test >>>> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >>>> fails on Alpine Linux >>>> ??? the test is excluded as part of the proposed patch. >>>> JDK-8241053 Hotspot >>>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >>>> fails on Alpine Linux with debug build >>>> ??? - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>> ??? - runtime/Thread/TestThreadStackSizes.java >>>> ??? tests are fixed as part of the proposed patch, David suggests >>>> to fix >>>> it in mainline as it does not seem to be specific to the port. I >>>> tend to >>>> agree with the evaluation. >>>> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >>>> ??? please see below >>>> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >>>> Linux >>>> ??? - test/jdk/com/sun/jdi/JdwpAllowTest.java >>>> ??? - test/jdk/com/sun/jdi/JdwpListenTest.java >>>> ??? Alex is looking into the reason of the issue. It could be >>>> because of >>>> the network settings on the host or the way the getaddrinfo(3) returns >>>> addresses in musl. Currently it looks to be not very specific to the >>>> port, though. >>>> >>>> These issues reflect the current testing status of the port. >>>>>> Build System, Toolchains: >>>>>> >>>>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>>>>> -f1" construct with sed to be slightly more robust >>>>>> - make/autoconf/build-aux/config.sub - style brought in line with >>>>>> the >>>>>> current file style >>>>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>>>> after JDK-8239450 [4] >>>>>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>>>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC >>>>>> warnings >>>>>> and modifying initialization is no longer required, Alpine Linux >>>>>> toolchain is quite recent >>>>> Great cleanups! Happy to see that the SA special casing is no longer >>>>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>>>> thank for that. >>>>> >>>>> * ReleaseFile.gmk >>>>> >>>>> The choice to use ?LIBC? as the key name in the releases file was >>>>> not something I/we spent a lot of time on, so we?ll want to revisit >>>>> that and make sure it?s the right name or come up with a better one. >>>> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle >>>> for >>>> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what >>>> came >>>> up as the least intrusive indication that musl is a kind of libc. >>>> Leaving it just as MUSL could be confusing. >>>>>> Desktop: >>>>>> >>>>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>>>> changes are >>>>>> present upstream and no longer required >>>>> Yay! >>>>> >>>>>> HotSpot: >>>>>> >>>>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>>>> logic >>>>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>>>> strerror is cleaner and more portable, the code originally present >>>>>> there >>>>>> is not thread-safe so it's ok to use it >>>>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a >>>>>> header >>>>>> instead >>>>> * os_linux.cpp >>>>> >>>>> Out of curiosity, have you tested with/without the various libnuma >>>>> library versions? >>>> Please see the updated version of the patch which is tested to work >>>> with >>>> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >>>> recognize library versions, and it only allows to install v1.2 in the >>>> distribution. It's good there is a single place where a change was >>>> required. >>>>> set_glibc_version -> set_libc_version? >>>> Fixed, thanks. >>>>> * globalDefinitions_gcc.hpp >>>>> >>>>> Did you verify that the change to use isnan instead of isnanf is >>>>> correct for all versions of linux/bsd and the respective (supported) >>>>> toolchain versions? See: >>>>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>>>> JEP in JBS. >>>> I updated JDK-8178689 with proof that such a replacement is safe >>>> for all >>>> practical combinations of gcc/glibc and llvm versions. >>>>> * ps_proc.c >>>>> >>>>> Hm.. What makes you say that the original code is not thread-safe? >>>> I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by >>>> corresponding syncronized constructs. >>>> >>>> That's because nobody claims that ptrace_attach is thread-safe or >>>> re-enterant. It depends to kernel implementation and attempt to use it >>>> from multiple threads could lead to completely unpredictable >>>> results. If >>>> we run ptrace_attach from different threads but with the same PID, it >>>> either crash the target process or fail. And it doesn't have any sense >>>> from serviceability agent point of view. >>>> >>>> Running ptrace_attach from multiple threads with different PIDs should >>>> be more or less OK - I trust modern kernel, but I don't see any >>>> usecase >>>> or command line support for using hotspot agent with multiple pids. >>>> >>>> So using strerror instead of strerror_r to mitigate compatibility >>>> issues >>>> should not be a problem. >>>>>> java.base: >>>>>> >>>>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>>>> - 2) >>>>>> a define >>>>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip >>>>>> this >>>>>> for now. Also, if the OS does not handle scripts without shebang it >>>>>> should not be emulated. >>>>> * jdk_util_md.h >>>>> >>>>> The same isnan comment as above. >>>> This is no longer relevant, fixed upstream. >>>>> * INTERRUPT_SIGNAL >>>>> >>>>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>>>> name) be moved to something like net_util_md.h so that it is shared >>>>> for both files using it? I?d also remove the spaces around the >>>>> arguments to pthread_kill in linux_close.c (pre-existing). >>>> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>>>> * java_md.c >>>>> >>>>> Did you look into alternatives ways to resolve the issue? As covered >>>>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>>>> could find some other way of dealing with that to avoid the the >>>>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >>>> Yes, but neither of them looked better [1, 2]. >>>>> * childproc.c >>>>> >>>>> Remind me: what happens without the fix? I?m thinking there was some >>>>> reason I made it to start with..? >>>> Without the fix we rely on the OS execve mechanism. On Alpine it does >>>> not currently handle files without shebang [3]. >>>>>> Tests: >>>>>> >>>>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>>>> - added WB_InternalVMInfo method to >>>>>> hotspot/share/prims/whitebox.cpp for >>>>>> better test handling >>>>>> - refactored affected tests to cater for the above >>>>> * VMProps.java >>>>> >>>>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>>>> may incorrectly return true if the VM info strings happens to >>>>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>>>> probably want something more targeted for the check. Also, the >>>>> pattern used in other places in the file to convert the boolean to a >>>>> String seems to be ?" + p. >>>> Yes, converted the check into >>>> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be >>>> more robust. >>>>> * exeinvoke.c >>>>> >>>>> I?m don?t know the "complicated interaction of signal handlers? well >>>>> enough to understand if the changes are correct, but assuming they >>>>> are: >>>>> >>>>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>>>> initialized (memset). >>>>> >>>>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>>>> should return a size_t? >>>>> >>>>> I?d also remove the spaces between pthread_ and the argument list >>>>> while your at it (also pre-existing), not exactly obvious why only >>>>> the pthread_ calls have them.. >>>> This is addressed in the updated webrev. >>>>> * exestack-tls.c >>>>> >>>>> As a potential alternative, base the decision on a define set by the >>>>> build system (MUSL_LIBC). Just something to consider. What you have >>>>> should work. >>>> I'd suggest to keep it as is - there is no other precedent of this in >>>> tests to support altering the build system. >>>>> * TestTerminatedThread.java >>>>> >>>>> I don?t know where we stand on adding comments, but personally I?d >>>>> prefer a comment explaining why the test is excluded when running >>>>> with musl (not unlike the one you have in NativeLibraryTest.java). >>>> Fixed in the updated webrev. >>>>> * Test7029048.java >>>>> >>>>> Can VMProps::isMusl be reused? I?m assuming that moving the >>>>> predicate definition to TestHelper would require a slew of tests to >>>>> use -XX:+WhiteBox? >>>> Yes, this is exactly the problem we try to avoid here. Another >>>> option is >>>> to introduce another helper class just for these couple of tests, but >>>> there would be only a couple of places where it would be used. >>>>> Also, I know I looked at this before but don?t remember the >>>>> conclusion: why is the check at the end ?passed < expected? rather >>>>> than exact match - passed == expected? (pre-existing) >>>> The test was refactored upstream and does not have any magic >>>> numbers any >>>> more [4]. The webrev is updated. >>>>> Finally a question: What level of testing have you done of this and >>>>> on which versions of Alpine/?? >>>> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux >>>> Arm, >>>> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >>>> regressions. A downport of these changes to 14 passes JCK 14 on these >>>> platforms. >>>> >>>> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. >>>> With >>>> the exception of the issues listed above and SA which is not supported >>>> as per the JEP, there are no differences with Linux x86_64. A downport >>>> of these changes to 14 passes JCK 14 on Alpine Linux. >>>> >>>> -Aleksei >>>> >>>> [1] https://www.openwall.com/lists/musl/2020/05/28/5 >>>> [2] https://www.openwall.com/lists/musl/2020/05/25/3 >>>> [3] https://www.openwall.com/lists/musl/2020/02/12/9 >>>> [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>>>> Cheers, >>>>> Mikael >>>>> >>>>>> Thanks, >>>>>> -Aleksei >>>>>> >>>>>> [1] https://openjdk.java.net/jeps/386 >>>>>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>>>>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 >>>>>> >>>>>> > From magnus.ihse.bursie at oracle.com Fri Aug 14 09:32:05 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 14 Aug 2020 11:32:05 +0200 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> Message-ID: <10c1823e-0ae9-65b7-de26-729b009266b9@oracle.com> Hi Aleksei, On 2020-08-13 15:59, Aleksei Voitylov wrote: > Hi Magnus, > > you are right: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.03/ Thank you! Now I'm fully happy! /Magnus > > -Aleksei > > On 13/08/2020 13:05, Magnus Ihse Bursie wrote: >> On 2020-08-12 18:58, Aleksei Voitylov wrote: >>> Hi Magnus, >>> >>> thank you for looking into it. Here is a webrev that addresses your >>> comments: >>> >>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ >> Thank you, looks much better! (If I may ask of anything more, it is to >> keep a consistent ordering OS -> CPU -> LIBC? where they all occur >> together. It helps keep your sanity up when reading the code) >> >> /Magnus >> >>> As far as code changes are concerned, I'd still like to seek consensus >>> within this project if the patch is overall good and has reached a point >>> to submit for pre-review upstream. Meanwhile, it was concluded that >>> JDK-8250630 is a generic issue that will be submitted upstream >>> separately - it has to do with linux networking stack configuration. >>> >>> -Aleksei >>> >>> On 10/08/2020 15:52, Magnus Ihse Bursie wrote: >>>> On 2020-07-28 19:20, Aleksei Voitylov wrote: >>>>> Hi Mikael, >>>>> >>>>> thank you for looking into it. Here is an updated version of the >>>>> webrev >>>>> with your comments addressed: >>>>> >>>>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ >>>> Some build comments: >>>> >>>> make/autoconf/build-aux/config.sub: >>>> I think you could match on just "linux-musl", to facilitate future >>>> ports to other architectures. >>>> >>>> make/autoconf/platform.m4: >>>> The new clib matching should move to a separate >>>> PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have >>>> been named "FOR" instead of "FROM"...) >>>> >>>> Apart from this, it looks good from a build perspective. >>>> >>>> /Magnus >>>>> Please see inline for details. >>>>> >>>>> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>>>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>>>>> patch [2] before moving the JEP to PTT and submitting for review >>>>>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor >>>>>>> cleanup >>>>>>> of the changes from the original portola branch [3] was made. >>>>>>> >>>>>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>> So glad to see that this is making progress, thanks a lot for >>>>>> picking it up! I?ve had a quick look at the changes and have a few >>>>>> initial comments, inlined below. I?ll also mention that I recently >>>>>> started the work of bringing the portola repo up-to-date again after >>>>>> the move to GitHub earlier this year. You?ll see that some of the >>>>>> changes I?m making there are not the same as the ones you have in >>>>>> this patch. Don?t read anything into that please - I started making >>>>>> those changes before I realized that you had this patch out for >>>>>> review and it wouldn?t surprise me if your version is preferable in >>>>>> many/most cases. Let?s figure out how to resolve that in the portola >>>>>> repo a bit later. >>>>>> >>>>>> Disclaimer: this is *not* a complete review, and should not be >>>>>> considered as blessing the changes for upstream/mainline. For that >>>>>> you?ll need to get the changes sent out to the respective lists >>>>>> (build-dev, hotspot-dev, ?). >>>>>> >>>>>> High level comment: There are a handful of JBS issues with Fix >>>>>> Version=repo-portola which would probably be good to have a look at >>>>>> and possibly close if they?re no longer relevant. >>>>>> >>>>> I did some bug scrubbing, here is the list of open issues: >>>>> >>>>> JDK-8241092 make test-bundles fails on Alpine Linux because of >>>>> TestTLS.java test >>>>> ??? is fixed as part of the proposed patch. >>>>> JDK-8240187 Test >>>>> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >>>>> fails on Alpine Linux >>>>> ??? the test is excluded as part of the proposed patch. >>>>> JDK-8241053 Hotspot >>>>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >>>>> fails on Alpine Linux with debug build >>>>> ??? - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> ??? - runtime/Thread/TestThreadStackSizes.java >>>>> ??? tests are fixed as part of the proposed patch, David suggests >>>>> to fix >>>>> it in mainline as it does not seem to be specific to the port. I >>>>> tend to >>>>> agree with the evaluation. >>>>> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >>>>> ??? please see below >>>>> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >>>>> Linux >>>>> ??? - test/jdk/com/sun/jdi/JdwpAllowTest.java >>>>> ??? - test/jdk/com/sun/jdi/JdwpListenTest.java >>>>> ??? Alex is looking into the reason of the issue. It could be >>>>> because of >>>>> the network settings on the host or the way the getaddrinfo(3) returns >>>>> addresses in musl. Currently it looks to be not very specific to the >>>>> port, though. >>>>> >>>>> These issues reflect the current testing status of the port. >>>>>>> Build System, Toolchains: >>>>>>> >>>>>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>>>>>> -f1" construct with sed to be slightly more robust >>>>>>> - make/autoconf/build-aux/config.sub - style brought in line with >>>>>>> the >>>>>>> current file style >>>>>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>>>>> after JDK-8239450 [4] >>>>>>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>>>>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC >>>>>>> warnings >>>>>>> and modifying initialization is no longer required, Alpine Linux >>>>>>> toolchain is quite recent >>>>>> Great cleanups! Happy to see that the SA special casing is no longer >>>>>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>>>>> thank for that. >>>>>> >>>>>> * ReleaseFile.gmk >>>>>> >>>>>> The choice to use ?LIBC? as the key name in the releases file was >>>>>> not something I/we spent a lot of time on, so we?ll want to revisit >>>>>> that and make sure it?s the right name or come up with a better one. >>>>> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle >>>>> for >>>>> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what >>>>> came >>>>> up as the least intrusive indication that musl is a kind of libc. >>>>> Leaving it just as MUSL could be confusing. >>>>>>> Desktop: >>>>>>> >>>>>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>>>>> changes are >>>>>>> present upstream and no longer required >>>>>> Yay! >>>>>> >>>>>>> HotSpot: >>>>>>> >>>>>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>>>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>>>>> logic >>>>>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>>>>> strerror is cleaner and more portable, the code originally present >>>>>>> there >>>>>>> is not thread-safe so it's ok to use it >>>>>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a >>>>>>> header >>>>>>> instead >>>>>> * os_linux.cpp >>>>>> >>>>>> Out of curiosity, have you tested with/without the various libnuma >>>>>> library versions? >>>>> Please see the updated version of the patch which is tested to work >>>>> with >>>>> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >>>>> recognize library versions, and it only allows to install v1.2 in the >>>>> distribution. It's good there is a single place where a change was >>>>> required. >>>>>> set_glibc_version -> set_libc_version? >>>>> Fixed, thanks. >>>>>> * globalDefinitions_gcc.hpp >>>>>> >>>>>> Did you verify that the change to use isnan instead of isnanf is >>>>>> correct for all versions of linux/bsd and the respective (supported) >>>>>> toolchain versions? See: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>>>>> JEP in JBS. >>>>> I updated JDK-8178689 with proof that such a replacement is safe >>>>> for all >>>>> practical combinations of gcc/glibc and llvm versions. >>>>>> * ps_proc.c >>>>>> >>>>>> Hm.. What makes you say that the original code is not thread-safe? >>>>> I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by >>>>> corresponding syncronized constructs. >>>>> >>>>> That's because nobody claims that ptrace_attach is thread-safe or >>>>> re-enterant. It depends to kernel implementation and attempt to use it >>>>> from multiple threads could lead to completely unpredictable >>>>> results. If >>>>> we run ptrace_attach from different threads but with the same PID, it >>>>> either crash the target process or fail. And it doesn't have any sense >>>>> from serviceability agent point of view. >>>>> >>>>> Running ptrace_attach from multiple threads with different PIDs should >>>>> be more or less OK - I trust modern kernel, but I don't see any >>>>> usecase >>>>> or command line support for using hotspot agent with multiple pids. >>>>> >>>>> So using strerror instead of strerror_r to mitigate compatibility >>>>> issues >>>>> should not be a problem. >>>>>>> java.base: >>>>>>> >>>>>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>>>>> - 2) >>>>>>> a define >>>>>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip >>>>>>> this >>>>>>> for now. Also, if the OS does not handle scripts without shebang it >>>>>>> should not be emulated. >>>>>> * jdk_util_md.h >>>>>> >>>>>> The same isnan comment as above. >>>>> This is no longer relevant, fixed upstream. >>>>>> * INTERRUPT_SIGNAL >>>>>> >>>>>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>>>>> name) be moved to something like net_util_md.h so that it is shared >>>>>> for both files using it? I?d also remove the spaces around the >>>>>> arguments to pthread_kill in linux_close.c (pre-existing). >>>>> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>>>>> * java_md.c >>>>>> >>>>>> Did you look into alternatives ways to resolve the issue? As covered >>>>>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>>>>> could find some other way of dealing with that to avoid the the >>>>>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >>>>> Yes, but neither of them looked better [1, 2]. >>>>>> * childproc.c >>>>>> >>>>>> Remind me: what happens without the fix? I?m thinking there was some >>>>>> reason I made it to start with..? >>>>> Without the fix we rely on the OS execve mechanism. On Alpine it does >>>>> not currently handle files without shebang [3]. >>>>>>> Tests: >>>>>>> >>>>>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>>>>> - added WB_InternalVMInfo method to >>>>>>> hotspot/share/prims/whitebox.cpp for >>>>>>> better test handling >>>>>>> - refactored affected tests to cater for the above >>>>>> * VMProps.java >>>>>> >>>>>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>>>>> may incorrectly return true if the VM info strings happens to >>>>>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>>>>> probably want something more targeted for the check. Also, the >>>>>> pattern used in other places in the file to convert the boolean to a >>>>>> String seems to be ?" + p. >>>>> Yes, converted the check into >>>>> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be >>>>> more robust. >>>>>> * exeinvoke.c >>>>>> >>>>>> I?m don?t know the "complicated interaction of signal handlers? well >>>>>> enough to understand if the changes are correct, but assuming they >>>>>> are: >>>>>> >>>>>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>>>>> initialized (memset). >>>>>> >>>>>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>>>>> should return a size_t? >>>>>> >>>>>> I?d also remove the spaces between pthread_ and the argument list >>>>>> while your at it (also pre-existing), not exactly obvious why only >>>>>> the pthread_ calls have them.. >>>>> This is addressed in the updated webrev. >>>>>> * exestack-tls.c >>>>>> >>>>>> As a potential alternative, base the decision on a define set by the >>>>>> build system (MUSL_LIBC). Just something to consider. What you have >>>>>> should work. >>>>> I'd suggest to keep it as is - there is no other precedent of this in >>>>> tests to support altering the build system. >>>>>> * TestTerminatedThread.java >>>>>> >>>>>> I don?t know where we stand on adding comments, but personally I?d >>>>>> prefer a comment explaining why the test is excluded when running >>>>>> with musl (not unlike the one you have in NativeLibraryTest.java). >>>>> Fixed in the updated webrev. >>>>>> * Test7029048.java >>>>>> >>>>>> Can VMProps::isMusl be reused? I?m assuming that moving the >>>>>> predicate definition to TestHelper would require a slew of tests to >>>>>> use -XX:+WhiteBox? >>>>> Yes, this is exactly the problem we try to avoid here. Another >>>>> option is >>>>> to introduce another helper class just for these couple of tests, but >>>>> there would be only a couple of places where it would be used. >>>>>> Also, I know I looked at this before but don?t remember the >>>>>> conclusion: why is the check at the end ?passed < expected? rather >>>>>> than exact match - passed == expected? (pre-existing) >>>>> The test was refactored upstream and does not have any magic >>>>> numbers any >>>>> more [4]. The webrev is updated. >>>>>> Finally a question: What level of testing have you done of this and >>>>>> on which versions of Alpine/?? >>>>> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux >>>>> Arm, >>>>> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >>>>> regressions. A downport of these changes to 14 passes JCK 14 on these >>>>> platforms. >>>>> >>>>> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. >>>>> With >>>>> the exception of the issues listed above and SA which is not supported >>>>> as per the JEP, there are no differences with Linux x86_64. A downport >>>>> of these changes to 14 passes JCK 14 on Alpine Linux. >>>>> >>>>> -Aleksei >>>>> >>>>> [1] https://www.openwall.com/lists/musl/2020/05/28/5 >>>>> [2] https://www.openwall.com/lists/musl/2020/05/25/3 >>>>> [3] https://www.openwall.com/lists/musl/2020/02/12/9 >>>>> [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>>> Thanks, >>>>>>> -Aleksei >>>>>>> >>>>>>> [1] https://openjdk.java.net/jeps/386 >>>>>>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>>>>>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 >>>>>>> >>>>>>> From mikael.vidstedt at oracle.com Thu Aug 20 20:26:41 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 20 Aug 2020 13:26:41 -0700 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> Message-ID: <8D829255-3778-407C-ACC3-A5F11D755C2D@oracle.com> This all looks really good, thanks for making the changes! Some very minor nit-picking: * make/ReleaseFile.gmk How about introducing a RELEASE_FILE_OS_LIBC for consistency? * src/hotspot/os/linux/os_linux.hpp Looks like the indentation is slightly off now for the code blocks where the ?g? got dropped. * src/hotspot/share/prims/whitebox.cpp Indent the "(void*)&WB_GetLibcName? part to match the other entries. The changes related to WAKEUP_SIGNAL and the isnan change are really not specific to musl, so it would certainly be possible and to me even _preferable_ to upstream them to mainline right away. Thoughts? I?d also like to see all of this pushed to the portola repo, more or less replacing the changes there today with some exceptions (jib-profiles.js being the key one, but there may be others). What do you think about that? Cheers, Mikael > On Aug 13, 2020, at 6:59 AM, Aleksei Voitylov wrote: > > Hi Magnus, > > you are right: http://cr.openjdk.java.net/~avoitylov/webrev.8247589.03/ > > -Aleksei > > On 13/08/2020 13:05, Magnus Ihse Bursie wrote: >> On 2020-08-12 18:58, Aleksei Voitylov wrote: >>> Hi Magnus, >>> >>> thank you for looking into it. Here is a webrev that addresses your >>> comments: >>> >>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ >> Thank you, looks much better! (If I may ask of anything more, it is to >> keep a consistent ordering OS -> CPU -> LIBC where they all occur >> together. It helps keep your sanity up when reading the code) >> >> /Magnus >> >>> >>> As far as code changes are concerned, I'd still like to seek consensus >>> within this project if the patch is overall good and has reached a point >>> to submit for pre-review upstream. Meanwhile, it was concluded that >>> JDK-8250630 is a generic issue that will be submitted upstream >>> separately - it has to do with linux networking stack configuration. >>> >>> -Aleksei >>> >>> On 10/08/2020 15:52, Magnus Ihse Bursie wrote: >>>> On 2020-07-28 19:20, Aleksei Voitylov wrote: >>>>> Hi Mikael, >>>>> >>>>> thank you for looking into it. Here is an updated version of the >>>>> webrev >>>>> with your comments addressed: >>>>> >>>>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ >>>> Some build comments: >>>> >>>> make/autoconf/build-aux/config.sub: >>>> I think you could match on just "linux-musl", to facilitate future >>>> ports to other architectures. >>>> >>>> make/autoconf/platform.m4: >>>> The new clib matching should move to a separate >>>> PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have >>>> been named "FOR" instead of "FROM"...) >>>> >>>> Apart from this, it looks good from a build perspective. >>>> >>>> /Magnus >>>>> Please see inline for details. >>>>> >>>>> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>>>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>>>>> patch [2] before moving the JEP to PTT and submitting for review >>>>>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor >>>>>>> cleanup >>>>>>> of the changes from the original portola branch [3] was made. >>>>>>> >>>>>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>> So glad to see that this is making progress, thanks a lot for >>>>>> picking it up! I?ve had a quick look at the changes and have a few >>>>>> initial comments, inlined below. I?ll also mention that I recently >>>>>> started the work of bringing the portola repo up-to-date again after >>>>>> the move to GitHub earlier this year. You?ll see that some of the >>>>>> changes I?m making there are not the same as the ones you have in >>>>>> this patch. Don?t read anything into that please - I started making >>>>>> those changes before I realized that you had this patch out for >>>>>> review and it wouldn?t surprise me if your version is preferable in >>>>>> many/most cases. Let?s figure out how to resolve that in the portola >>>>>> repo a bit later. >>>>>> >>>>>> Disclaimer: this is *not* a complete review, and should not be >>>>>> considered as blessing the changes for upstream/mainline. For that >>>>>> you?ll need to get the changes sent out to the respective lists >>>>>> (build-dev, hotspot-dev, ?). >>>>>> >>>>>> High level comment: There are a handful of JBS issues with Fix >>>>>> Version=repo-portola which would probably be good to have a look at >>>>>> and possibly close if they?re no longer relevant. >>>>>> >>>>> I did some bug scrubbing, here is the list of open issues: >>>>> >>>>> JDK-8241092 make test-bundles fails on Alpine Linux because of >>>>> TestTLS.java test >>>>> is fixed as part of the proposed patch. >>>>> JDK-8240187 Test >>>>> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >>>>> fails on Alpine Linux >>>>> the test is excluded as part of the proposed patch. >>>>> JDK-8241053 Hotspot >>>>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >>>>> fails on Alpine Linux with debug build >>>>> - runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>> - runtime/Thread/TestThreadStackSizes.java >>>>> tests are fixed as part of the proposed patch, David suggests >>>>> to fix >>>>> it in mainline as it does not seem to be specific to the port. I >>>>> tend to >>>>> agree with the evaluation. >>>>> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >>>>> please see below >>>>> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >>>>> Linux >>>>> - test/jdk/com/sun/jdi/JdwpAllowTest.java >>>>> - test/jdk/com/sun/jdi/JdwpListenTest.java >>>>> Alex is looking into the reason of the issue. It could be >>>>> because of >>>>> the network settings on the host or the way the getaddrinfo(3) returns >>>>> addresses in musl. Currently it looks to be not very specific to the >>>>> port, though. >>>>> >>>>> These issues reflect the current testing status of the port. >>>>>>> Build System, Toolchains: >>>>>>> >>>>>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 | cut >>>>>>> -f1" construct with sed to be slightly more robust >>>>>>> - make/autoconf/build-aux/config.sub - style brought in line with >>>>>>> the >>>>>>> current file style >>>>>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>>>>> after JDK-8239450 [4] >>>>>>> - make/modules/jdk.jdwp.agent/Lib.gmk, make/test/JtregNativeJdk.gmk, >>>>>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC >>>>>>> warnings >>>>>>> and modifying initialization is no longer required, Alpine Linux >>>>>>> toolchain is quite recent >>>>>> Great cleanups! Happy to see that the SA special casing is no longer >>>>>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>>>>> thank for that. >>>>>> >>>>>> * ReleaseFile.gmk >>>>>> >>>>>> The choice to use ?LIBC? as the key name in the releases file was >>>>>> not something I/we spent a lot of time on, so we?ll want to revisit >>>>>> that and make sure it?s the right name or come up with a better one. >>>>> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle >>>>> for >>>>> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what >>>>> came >>>>> up as the least intrusive indication that musl is a kind of libc. >>>>> Leaving it just as MUSL could be confusing. >>>>>>> Desktop: >>>>>>> >>>>>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>>>>> changes are >>>>>>> present upstream and no longer required >>>>>> Yay! >>>>>> >>>>>>> HotSpot: >>>>>>> >>>>>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>>>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>>>>> logic >>>>>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>>>>> strerror is cleaner and more portable, the code originally present >>>>>>> there >>>>>>> is not thread-safe so it's ok to use it >>>>>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a >>>>>>> header >>>>>>> instead >>>>>> * os_linux.cpp >>>>>> >>>>>> Out of curiosity, have you tested with/without the various libnuma >>>>>> library versions? >>>>> Please see the updated version of the patch which is tested to work >>>>> with >>>>> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >>>>> recognize library versions, and it only allows to install v1.2 in the >>>>> distribution. It's good there is a single place where a change was >>>>> required. >>>>>> set_glibc_version -> set_libc_version? >>>>> Fixed, thanks. >>>>>> * globalDefinitions_gcc.hpp >>>>>> >>>>>> Did you verify that the change to use isnan instead of isnanf is >>>>>> correct for all versions of linux/bsd and the respective (supported) >>>>>> toolchain versions? See: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>>>>> JEP in JBS. >>>>> I updated JDK-8178689 with proof that such a replacement is safe >>>>> for all >>>>> practical combinations of gcc/glibc and llvm versions. >>>>>> * ps_proc.c >>>>>> >>>>>> Hm.. What makes you say that the original code is not thread-safe? >>>>> I checked LinuxDebuggerLocal.java and all attach0 calls are guarded by >>>>> corresponding syncronized constructs. >>>>> >>>>> That's because nobody claims that ptrace_attach is thread-safe or >>>>> re-enterant. It depends to kernel implementation and attempt to use it >>>>> from multiple threads could lead to completely unpredictable >>>>> results. If >>>>> we run ptrace_attach from different threads but with the same PID, it >>>>> either crash the target process or fail. And it doesn't have any sense >>>>> from serviceability agent point of view. >>>>> >>>>> Running ptrace_attach from multiple threads with different PIDs should >>>>> be more or less OK - I trust modern kernel, but I don't see any >>>>> usecase >>>>> or command line support for using hotspot agent with multiple pids. >>>>> >>>>> So using strerror instead of strerror_r to mitigate compatibility >>>>> issues >>>>> should not be a problem. >>>>>>> java.base: >>>>>>> >>>>>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>>>>> - 2) >>>>>>> a define >>>>>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip >>>>>>> this >>>>>>> for now. Also, if the OS does not handle scripts without shebang it >>>>>>> should not be emulated. >>>>>> * jdk_util_md.h >>>>>> >>>>>> The same isnan comment as above. >>>>> This is no longer relevant, fixed upstream. >>>>>> * INTERRUPT_SIGNAL >>>>>> >>>>>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>>>>> name) be moved to something like net_util_md.h so that it is shared >>>>>> for both files using it? I?d also remove the spaces around the >>>>>> arguments to pthread_kill in linux_close.c (pre-existing). >>>>> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>>>>> * java_md.c >>>>>> >>>>>> Did you look into alternatives ways to resolve the issue? As covered >>>>>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>>>>> could find some other way of dealing with that to avoid the the >>>>>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >>>>> Yes, but neither of them looked better [1, 2]. >>>>>> * childproc.c >>>>>> >>>>>> Remind me: what happens without the fix? I?m thinking there was some >>>>>> reason I made it to start with..? >>>>> Without the fix we rely on the OS execve mechanism. On Alpine it does >>>>> not currently handle files without shebang [3]. >>>>>>> Tests: >>>>>>> >>>>>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>>>>> - added WB_InternalVMInfo method to >>>>>>> hotspot/share/prims/whitebox.cpp for >>>>>>> better test handling >>>>>>> - refactored affected tests to cater for the above >>>>>> * VMProps.java >>>>>> >>>>>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>>>>> may incorrectly return true if the VM info strings happens to >>>>>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>>>>> probably want something more targeted for the check. Also, the >>>>>> pattern used in other places in the file to convert the boolean to a >>>>>> String seems to be ?" + p. >>>>> Yes, converted the check into >>>>> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this should be >>>>> more robust. >>>>>> * exeinvoke.c >>>>>> >>>>>> I?m don?t know the "complicated interaction of signal handlers? well >>>>>> enough to understand if the changes are correct, but assuming they >>>>>> are: >>>>>> >>>>>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>>>>> initialized (memset). >>>>>> >>>>>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>>>>> should return a size_t? >>>>>> >>>>>> I?d also remove the spaces between pthread_ and the argument list >>>>>> while your at it (also pre-existing), not exactly obvious why only >>>>>> the pthread_ calls have them.. >>>>> This is addressed in the updated webrev. >>>>>> * exestack-tls.c >>>>>> >>>>>> As a potential alternative, base the decision on a define set by the >>>>>> build system (MUSL_LIBC). Just something to consider. What you have >>>>>> should work. >>>>> I'd suggest to keep it as is - there is no other precedent of this in >>>>> tests to support altering the build system. >>>>>> * TestTerminatedThread.java >>>>>> >>>>>> I don?t know where we stand on adding comments, but personally I?d >>>>>> prefer a comment explaining why the test is excluded when running >>>>>> with musl (not unlike the one you have in NativeLibraryTest.java). >>>>> Fixed in the updated webrev. >>>>>> * Test7029048.java >>>>>> >>>>>> Can VMProps::isMusl be reused? I?m assuming that moving the >>>>>> predicate definition to TestHelper would require a slew of tests to >>>>>> use -XX:+WhiteBox? >>>>> Yes, this is exactly the problem we try to avoid here. Another >>>>> option is >>>>> to introduce another helper class just for these couple of tests, but >>>>> there would be only a couple of places where it would be used. >>>>>> Also, I know I looked at this before but don?t remember the >>>>>> conclusion: why is the check at the end ?passed < expected? rather >>>>>> than exact match - passed == expected? (pre-existing) >>>>> The test was refactored upstream and does not have any magic >>>>> numbers any >>>>> more [4]. The webrev is updated. >>>>>> Finally a question: What level of testing have you done of this and >>>>>> on which versions of Alpine/?? >>>>> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux >>>>> Arm, >>>>> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >>>>> regressions. A downport of these changes to 14 passes JCK 14 on these >>>>> platforms. >>>>> >>>>> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. >>>>> With >>>>> the exception of the issues listed above and SA which is not supported >>>>> as per the JEP, there are no differences with Linux x86_64. A downport >>>>> of these changes to 14 passes JCK 14 on Alpine Linux. >>>>> >>>>> -Aleksei >>>>> >>>>> [1] https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/05/28/5__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdsgKGnV3w$ >>>>> [2] https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/05/25/3__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdsp8FgoM5$ >>>>> [3] https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/02/12/9__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdstJH5-RH$ >>>>> [4] http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>>>>> Cheers, >>>>>> Mikael >>>>>> >>>>>>> Thanks, >>>>>>> -Aleksei >>>>>>> >>>>>>> [1] https://openjdk.java.net/jeps/386 >>>>>>> [2] http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8247589 ) >>>>>>> [3] http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8239450 From mikael at openjdk.java.net Thu Aug 20 23:17:06 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 20 Aug 2020 23:17:06 GMT Subject: RFR: Merge jdk Message-ID: Merge in jdk-15+36 ------------- Commit messages: - Merge jdk - 8246031: SSLSocket.getSession() doesn't close connection for timeout/ interrupts - 8251276: JDK-8248299 breaks JDK 15 validate-headers build - 8248299: two jdeps files miss copyright header - Added tag jdk-15+35 for changeset fd60c3146a02 - 8249628: Remove EA from JDK 15 version string starting with Initial RC promotion - 8250609: C2 crash in IfNode::fold_compares - 8248597: [Graal] api/java_security/SignatureSpi/DelegationTests.html fails with Method "javasoft.sqe.tests.api.java.security.SignatureSpi.JCKSignatureSpi.clear" doesn't exist - 8250770: Net.java translateToSocketException does not handle IOException - Added tag jdk-15+34 for changeset b0817631d2f4 - ... and 91 more: https://git.openjdk.java.net/portola/compare/0b2dbf5c...bc96df28 The webrevs contain the adjustments done while merging with regards to each parent branch: - jdk15: https://webrevs.openjdk.java.net/portola/10/webrev.00.0 - jdk: https://webrevs.openjdk.java.net/portola/10/webrev.00.1 Changes: https://git.openjdk.java.net/portola/pull/10/files Stats: 10268 lines in 2887 files changed: 3563 ins; 3483 del; 3222 mod Patch: https://git.openjdk.java.net/portola/pull/10.diff Fetch: git fetch https://git.openjdk.java.net/portola pull/10/head:pull/10 PR: https://git.openjdk.java.net/portola/pull/10 From mikael at openjdk.java.net Thu Aug 20 23:17:50 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 20 Aug 2020 23:17:50 GMT Subject: Integrated: Merge jdk In-Reply-To: References: Message-ID: On Thu, 20 Aug 2020 23:01:48 GMT, Mikael Vidstedt wrote: > Merge in jdk-15+36 This pull request has now been integrated. Changeset: 0c8f7c92 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/portola/commit/0c8f7c92 Stats: 10258 lines in 2887 files changed: 3473 ins; 3553 del; 3232 mod Merge jdk ------------- PR: https://git.openjdk.java.net/portola/pull/10 From mikael at openjdk.java.net Fri Aug 21 04:18:51 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 21 Aug 2020 04:18:51 GMT Subject: RFR: Merge jdk Message-ID: Merge in jdk-16+12 ------------- Commit messages: - Merge jdk - 8251499: no-placeholder compact number patterns throw IllegalArgumentException - 8251490: [TESTBUG] The Java thread stack size specified is too small for nsk/stress/stack. Specify at least 448k - 8251454: Wrong "self type" in DCTree.DCEndElement - 8251357: [DocCommentParser] Infinite loop while looking for the end of a preamble - 8246047: Replace LinkedList impl in net.http.websocket.BuilderImpl - 8251888: Move HotSpot Style Guide wiki subpages to jdk/jdk/doc - 8251715: Throw UncheckedIOException in place of InternalError when HttpClient fails due to unavailability of underlying resources required by SSLContext - 8250748: Doc of URL(String, String, int, String, URLStreamHandler) does not use link - 8249902: tools/javac/records/mandated_members/read_resolve_method/CheckReadResolveMethodTest.java uses @ignore w/o bug-id - ... and 516 more: https://git.openjdk.java.net/portola/compare/45171054...c0fc2582 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.java.net/portola/11/webrev.00.0 - jdk: https://webrevs.openjdk.java.net/portola/11/webrev.00.1 Changes: https://git.openjdk.java.net/portola/pull/11/files Stats: 53394 lines in 5602 files changed: 27056 ins; 14201 del; 12137 mod Patch: https://git.openjdk.java.net/portola/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/portola pull/11/head:pull/11 PR: https://git.openjdk.java.net/portola/pull/11 From mikael at openjdk.java.net Fri Aug 21 05:58:59 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 21 Aug 2020 05:58:59 GMT Subject: RFR: Merge jdk [v2] In-Reply-To: References: Message-ID: > Merge in jdk-16+12 Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits: - Merge jdk - Merge jdk - Merge jdk - Merge jdk - Merge jdk - Merge jdk - Merge jdk - Update .jcheck/conf - Fix test/jdk/tools/launcher/Test7029048.java - Merge - ... and 61 more: https://git.openjdk.java.net/portola/compare/49e7609d...c0fc2582 ------------- Changes: https://git.openjdk.java.net/portola/pull/11/files Webrev: https://webrevs.openjdk.java.net/portola/11/webrev.01 Stats: 522 lines in 36 files changed: 442 ins; 5 del; 75 mod Patch: https://git.openjdk.java.net/portola/pull/11.diff Fetch: git fetch https://git.openjdk.java.net/portola pull/11/head:pull/11 PR: https://git.openjdk.java.net/portola/pull/11 From mikael at openjdk.java.net Fri Aug 21 05:59:04 2020 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 21 Aug 2020 05:59:04 GMT Subject: Integrated: Merge jdk In-Reply-To: References: Message-ID: On Fri, 21 Aug 2020 04:09:17 GMT, Mikael Vidstedt wrote: > Merge in jdk-16+12 This pull request has now been integrated. Changeset: 3010a3d4 Author: Mikael Vidstedt URL: https://git.openjdk.java.net/portola/commit/3010a3d4 Stats: 53367 lines in 5602 files changed: 14174 ins; 27029 del; 12164 mod Merge jdk ------------- PR: https://git.openjdk.java.net/portola/pull/11 From Alan.Bateman at oracle.com Wed Aug 26 12:09:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Aug 2020 13:09:07 +0100 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> Message-ID: <0d0fe5f8-0256-7928-f31b-637704ecde4d@oracle.com> On 08/07/2020 19:52, Mikael Vidstedt wrote: >> java.base: >> >> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX - 2) >> a define >> - src/java.base/unix/native/libjava/childproc.c - suggest to skip this >> for now. Also, if the OS does not handle scripts without shebang it >> should not be emulated. > * jdk_util_md.h > > The same isnan comment as above. > > * INTERRUPT_SIGNAL > > Can the definition of INTERRUPT_SIGNAL (perhaps then with a better name) be moved to something like net_util_md.h so that it is shared for both files using it? I?d also remove the spaces around the arguments to pthread_kill in linux_close.c (pre-existing). > This came up in the review of JDK-8252248 on core-libs-dev too. The xxx_close.c sources will be removed when the legacy (and not used by default) PlainSocketImpl and PlainDatagramSocketImpl go away. Also NativeThread.c is for signalling in the FileChannel implementation so shouldn't have a dependency on net_util. -Alan From alexsch at openjdk.java.net Fri Aug 28 10:17:53 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 28 Aug 2020 10:17:53 GMT Subject: RFR: JEP 386 patch - minor cleanup Message-ID: "JEP 386 patch - minor cleanup" changes discussed on portola-dev alias: https://mail.openjdk.java.net/pipermail/portola-dev/2020-August/000471.html Changed: * RELEASE_FILE_OS_LIBC is introduced in make files * glibc_version is renamed to libc_version * added fix for numa_node_to_cpus NUMA method * WhiteBox is used to check musl libc in tests * Platform.isBusybox(tool) method is added to check busybox in tests Removed: * HOTSPOT_TARGET_LIBC flag * workaround for issues for execvp file call in childproc.c file * workaround for coredump issue in ps_core.c file Skipped: * isnanf change from globalDefinitions_gcc.hpp * SIGRTMAX changes from NativeThread.c and linux_close.c files ------------- Commit messages: - JEP 386 patch - Do not workaround code for coredump. Fix it as a separate issue. - JEP 386 patch - remove unused imports from VMProps.java - JEP 386 patch - fix identation in libc_version declaration - JEP 386 patch - introduce RELEASE_FILE_LIBC - JEP 386 patch - fix identantion in TestInheritFD.java test - JEP 386 patch - remove isMuslLibc() method from TestHelper.java (it is replaced by WhiteBox call) - JEP 386 patch - remove execvp() workaround from childproc.c - JEP 386 patch - remove smallest_ptr initialization from genCollectedHeap.cpp - JEP 386 patch - remove INCLUDE_SA_ATTACH flag - JEP 386 patch - remove OPENJDK_TARGET_LIBC and stringop-truncation flags from make files - ... and 17 more: https://git.openjdk.java.net/portola/compare/3010a3d4...4d1aacd5 Changes: https://git.openjdk.java.net/portola/pull/12/files Webrev: https://webrevs.openjdk.java.net/portola/12/webrev.00 Stats: 392 lines in 35 files changed: 137 ins; 135 del; 120 mod Patch: https://git.openjdk.java.net/portola/pull/12.diff Fetch: git fetch https://git.openjdk.java.net/portola pull/12/head:pull/12 PR: https://git.openjdk.java.net/portola/pull/12 From aleksei.voitylov at bell-sw.com Mon Aug 31 13:24:08 2020 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 31 Aug 2020 16:24:08 +0300 Subject: RFC: JEP 386 patch - minor cleanup In-Reply-To: <8D829255-3778-407C-ACC3-A5F11D755C2D@oracle.com> References: <149021db-ee54-463c-1162-33574d9381f3@bell-sw.com> <1B3C9BE0-B7A7-4F9B-9486-EC2AB0205B19@oracle.com> <384405ef-9e40-026d-089d-4ebee107a505@bell-sw.com> <78e3d188-8306-9c53-9e1a-35fc5d34b5fb@oracle.com> <4a89edda-0f10-6636-d7d1-7720846e0fa3@bell-sw.com> <3a219042-bc6c-46f9-db9d-81d3e2c78c7d@oracle.com> <07b0f5b9-9d63-4c39-5a2b-c48f16b42a81@bell-sw.com> <8D829255-3778-407C-ACC3-A5F11D755C2D@oracle.com> Message-ID: <0589b966-22c9-3d36-6201-5dbe39e17e5e@bell-sw.com> Hi Mikael, thank you for the final nit-picking. I believe at this point we have resolved all the issues you and Magnus pointed out to, and the WAKEUP_SIGNAL [1] and isnan [2] fixes are upstream. Alex has created a pull request into the git portola repo, and I plan to send the RFC to hotspot-dev tomorrow. -Aleksei [1] https://bugs.openjdk.java.net/browse/JDK-8252248 [2] https://bugs.openjdk.java.net/browse/JDK-8252250 On 20/08/2020 23:26, Mikael Vidstedt wrote: > > This all looks really good, thanks for making the changes! Some very > minor nit-picking: > > * make/ReleaseFile.gmk? > > How about introducing a RELEASE_FILE_OS_LIBC for consistency? > > *?src/hotspot/os/linux/os_linux.hpp > > Looks like the indentation is slightly off now for the code blocks > where the ?g? got dropped. > > *?src/hotspot/share/prims/whitebox.cpp > > Indent the "(void*)&WB_GetLibcName? part to match the other entries. > > > The changes related to WAKEUP_SIGNAL and the isnan change are really > not specific to musl, so it would certainly be possible and to me even > _preferable_ to upstream them to mainline right away. Thoughts? > > I?d also like to see all of this pushed to the portola repo, more or > less replacing the changes there today with some exceptions > (jib-profiles.js being the key one, but there may be others). What do > you think about that? > > Cheers, > Mikael > >> On Aug 13, 2020, at 6:59 AM, Aleksei Voitylov >> > >> wrote: >> >> Hi Magnus, >> >> you are right:?http://cr.openjdk.java.net/~avoitylov/webrev.8247589.03/ >> >> -Aleksei >> >> On 13/08/2020 13:05, Magnus Ihse Bursie wrote: >>> On 2020-08-12 18:58, Aleksei Voitylov wrote: >>>> Hi Magnus, >>>> >>>> thank you for looking into it. Here is a webrev that addresses your >>>> comments: >>>> >>>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.02/ >>> Thank you, looks much better! (If I may ask of anything more, it is to >>> keep a consistent ordering OS -> CPU -> LIBC? where they all occur >>> together. It helps keep your sanity up when reading the code) >>> >>> /Magnus >>> >>>> >>>> As far as code changes are concerned, I'd still like to seek consensus >>>> within this project if the patch is overall good and has reached a >>>> point >>>> to submit for pre-review upstream. Meanwhile, it was concluded that >>>> JDK-8250630 is a generic issue that will be submitted upstream >>>> separately - it has to do with linux networking stack configuration. >>>> >>>> -Aleksei >>>> >>>> On 10/08/2020 15:52, Magnus Ihse Bursie wrote: >>>>> On 2020-07-28 19:20, Aleksei Voitylov wrote: >>>>>> Hi Mikael, >>>>>> >>>>>> thank you for looking into it. Here is an updated version of the >>>>>> webrev >>>>>> with your comments addressed: >>>>>> >>>>>> http://cr.openjdk.java.net/~avoitylov/webrev.8247589.01/ >>>>> Some build comments: >>>>> >>>>> make/autoconf/build-aux/config.sub: >>>>> I think you could match on just "linux-musl", to facilitate future >>>>> ports to other architectures. >>>>> >>>>> make/autoconf/platform.m4: >>>>> The new clib matching should move to a separate >>>>> PLATFORM_EXTRACT_VARS_FROM_CLIB function. (Maybe these should have >>>>> been named "FOR" instead of "FROM"...) >>>>> >>>>> Apart from this, it looks good from a build perspective. >>>>> >>>>> /Magnus >>>>>> Please see inline for details. >>>>>> >>>>>> On 08/07/2020 21:52, Mikael Vidstedt wrote: >>>>>>>> On Jun 26, 2020, at 5:00 AM, Aleksei Voitylov >>>>>>>> >>>>>>> > wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> As JEP 386 is now Candidate [1] I'd like to request comments on the >>>>>>>> patch [2] before moving the JEP to PTT and submitting for review >>>>>>>> upstream. The patch is rebased to 59791:a22af2c3d969 and minor >>>>>>>> cleanup >>>>>>>> of the changes from the original portola branch [3] was made. >>>>>>>> >>>>>>>> Webrev [2]: http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>>> Original [3]: http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>>> So glad to see that this is making progress, thanks a lot for >>>>>>> picking it up! I?ve had a quick look at the changes and have a few >>>>>>> initial comments, inlined below. I?ll also mention that I recently >>>>>>> started the work of bringing the portola repo up-to-date again after >>>>>>> the move to GitHub earlier this year. You?ll see that some of the >>>>>>> changes I?m making there are not the same as the ones you have in >>>>>>> this patch. Don?t read anything into that please - I started making >>>>>>> those changes before I realized that you had this patch out for >>>>>>> review and it wouldn?t surprise me if your version is preferable in >>>>>>> many/most cases. Let?s figure out how to resolve that in the portola >>>>>>> repo a bit later. >>>>>>> >>>>>>> Disclaimer: this is *not* a complete review, and should not be >>>>>>> considered as blessing the changes for upstream/mainline. For that >>>>>>> you?ll need to get the changes sent out to the respective lists >>>>>>> (build-dev, hotspot-dev, ?). >>>>>>> >>>>>>> High level comment: There are a handful of JBS issues with Fix >>>>>>> Version=repo-portola which would probably be good to have a look at >>>>>>> and possibly close if they?re no longer relevant. >>>>>>> >>>>>> I did some bug scrubbing, here is the list of open issues: >>>>>> >>>>>> JDK-8241092 make test-bundles fails on Alpine Linux because of >>>>>> TestTLS.java test >>>>>> ????is fixed as part of the proposed patch. >>>>>> JDK-8240187 Test >>>>>> hotspot/jtreg/runtime/jni/terminatedThread/TestTerminatedThread.java >>>>>> fails on Alpine Linux >>>>>> ????the test is excluded as part of the proposed patch. >>>>>> JDK-8241053 Hotspot >>>>>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java test >>>>>> fails on Alpine Linux with debug build >>>>>> ????- >>>>>> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >>>>>> ????- runtime/Thread/TestThreadStackSizes.java >>>>>> ????tests are fixed as part of the proposed patch, David suggests >>>>>> to fix >>>>>> it in mainline as it does not seem to be specific to the port. I >>>>>> tend to >>>>>> agree with the evaluation. >>>>>> JDK-8178692 Clean up RequiresSetenv / LD_LIBRARY_PATH >>>>>> ????please see below >>>>>> JDK-8250630 test/jdk/com/sun/jdi/JdwpListenTest.java fails on Alpine >>>>>> Linux >>>>>> ????- test/jdk/com/sun/jdi/JdwpAllowTest.java >>>>>> ????- test/jdk/com/sun/jdi/JdwpListenTest.java >>>>>> ????Alex is looking into the reason of the issue. It could be >>>>>> because of >>>>>> the network settings on the host or the way the getaddrinfo(3) >>>>>> returns >>>>>> addresses in musl. Currently it looks to be not very specific to the >>>>>> port, though. >>>>>> >>>>>> These issues reflect the current testing status of the port. >>>>>>>> Build System, Toolchains: >>>>>>>> >>>>>>>> - make/autoconf/build-aux/config.guess - replaced the "head -1 >>>>>>>> | cut >>>>>>>> -f1" construct with sed to be slightly more robust >>>>>>>> - make/autoconf/build-aux/config.sub - style brought in line with >>>>>>>> the >>>>>>>> current file style >>>>>>>> - make/autoconf/hotspot.m4 - HOTSPOT_SETUP_SA is no longer required >>>>>>>> after JDK-8239450 [4] >>>>>>>> - make/modules/jdk.jdwp.agent/Lib.gmk, >>>>>>>> make/test/JtregNativeJdk.gmk, >>>>>>>> hotspot/share/gc/shared/genCollectedHeap.cpp - disabling GCC >>>>>>>> warnings >>>>>>>> and modifying initialization is no longer required, Alpine Linux >>>>>>>> toolchain is quite recent >>>>>>> Great cleanups! Happy to see that the SA special casing is no longer >>>>>>> needed - https://bugs.openjdk.java.net/browse/JDK-8181313 is also to >>>>>>> thank for that. >>>>>>> >>>>>>> * ReleaseFile.gmk >>>>>>> >>>>>>> The choice to use ?LIBC? as the key name in the releases file was >>>>>>> not something I/we spent a lot of time on, so we?ll want to revisit >>>>>>> that and make sure it?s the right name or come up with a better one. >>>>>> For ReleaseFile.gmk I think LIBC is good, as it is used as a handle >>>>>> for >>>>>> the actual OPENJDK_TARGET_LIBC. For source code, MUSL_LIBC is what >>>>>> came >>>>>> up as the least intrusive indication that musl is a kind of libc. >>>>>> Leaving it just as MUSL could be confusing. >>>>>>>> Desktop: >>>>>>>> >>>>>>>> - src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c - >>>>>>>> changes are >>>>>>>> present upstream and no longer required >>>>>>> Yay! >>>>>>> >>>>>>>> HotSpot: >>>>>>>> >>>>>>>> - src/hotspot/os/linux/os_linux.cpp - checks for MUSL can be made >>>>>>>> static. Defined stub dlvsym for MUSL instead of dlvsym_if_available >>>>>>>> logic >>>>>>>> - src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c - using >>>>>>>> strerror is cleaner and more portable, the code originally present >>>>>>>> there >>>>>>>> is not thread-safe so it's ok to use it >>>>>>>> - src/jdk.jdwp.agent/share/native/libjdwp/util.h - including a >>>>>>>> header >>>>>>>> instead >>>>>>> * os_linux.cpp >>>>>>> >>>>>>> Out of curiosity, have you tested with/without the various libnuma >>>>>>> library versions? >>>>>> Please see the updated version of the patch which is tested to work >>>>>> with >>>>>> (and without) libnuma v1.2 on Alpine Linux. Note that musl can't >>>>>> recognize library versions, and it only allows to install v1.2 in the >>>>>> distribution. It's good there is a single place where a change was >>>>>> required. >>>>>>> set_glibc_version -> set_libc_version? >>>>>> Fixed, thanks. >>>>>>> * globalDefinitions_gcc.hpp >>>>>>> >>>>>>> Did you verify that the change to use isnan instead of isnanf is >>>>>>> correct for all versions of linux/bsd and the respective (supported) >>>>>>> toolchain versions? See: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8178689. I linked it to the >>>>>>> JEP in JBS. >>>>>> I updated JDK-8178689 with proof that such a replacement is safe >>>>>> for all >>>>>> practical combinations of gcc/glibc and llvm versions. >>>>>>> * ps_proc.c >>>>>>> >>>>>>> Hm.. What makes you say that the original code is not thread-safe? >>>>>> I checked LinuxDebuggerLocal.java and all attach0 calls are >>>>>> guarded by >>>>>> corresponding syncronized constructs. >>>>>> >>>>>> That's because nobody claims that ptrace_attach is thread-safe or >>>>>> re-enterant. It depends to kernel implementation and attempt to >>>>>> use it >>>>>> from multiple threads could lead to completely unpredictable >>>>>> results. If >>>>>> we run ptrace_attach from different threads but with the same PID, it >>>>>> either crash the target process or fail. And it doesn't have any >>>>>> sense >>>>>> from serviceability agent point of view. >>>>>> >>>>>> Running ptrace_attach from multiple threads with different PIDs >>>>>> should >>>>>> be more or less OK - I trust modern kernel, but I don't see any >>>>>> usecase >>>>>> or command line support for using hotspot agent with multiple pids. >>>>>> >>>>>> So using strerror instead of strerror_r to mitigate compatibility >>>>>> issues >>>>>> should not be a problem. >>>>>>>> java.base: >>>>>>>> >>>>>>>> - src/java.base/linux/native/libnet/linux_close.c - made (SIGRTMAX >>>>>>>> - 2) >>>>>>>> a define >>>>>>>> - src/java.base/unix/native/libjava/childproc.c - suggest to skip >>>>>>>> this >>>>>>>> for now. Also, if the OS does not handle scripts without shebang it >>>>>>>> should not be emulated. >>>>>>> * jdk_util_md.h >>>>>>> >>>>>>> The same isnan comment as above. >>>>>> This is no longer relevant, fixed upstream. >>>>>>> * INTERRUPT_SIGNAL >>>>>>> >>>>>>> Can the definition of INTERRUPT_SIGNAL (perhaps then with a better >>>>>>> name) be moved to something like net_util_md.h so that it is shared >>>>>>> for both files using it? I?d also remove the spaces around the >>>>>>> arguments to pthread_kill in linux_close.c (pre-existing). >>>>>> Done, renamed INTERRUPT_SIGNAL to WAKEUP_SIGNAL. >>>>>>> * java_md.c >>>>>>> >>>>>>> Did you look into alternatives ways to resolve the issue? As covered >>>>>>> by https://bugs.openjdk.java.net/browse/JDK-8178692 I was hoping we >>>>>>> could find some other way of dealing with that to avoid the the >>>>>>> LD_LIBRARY_PATH dance and the ugly/fragile fallout from it. >>>>>> Yes, but neither of them looked better [1, 2]. >>>>>>> * childproc.c >>>>>>> >>>>>>> Remind me: what happens without the fix? I?m thinking there was some >>>>>>> reason I made it to start with..? >>>>>> Without the fix we rely on the OS execve mechanism. On Alpine it does >>>>>> not currently handle files without shebang [3]. >>>>>>>> Tests: >>>>>>>> >>>>>>>> - added method isBusyBox() to test/lib/jdk/test/lib/Platform.java >>>>>>>> - added WB_InternalVMInfo method to >>>>>>>> hotspot/share/prims/whitebox.cpp for >>>>>>>> better test handling >>>>>>>> - refactored affected tests to cater for the above >>>>>>> * VMProps.java >>>>>>> >>>>>>> If I read it correctly I think WB.internalVMInfo().contains("musl?) >>>>>>> may incorrectly return true if the VM info strings happens to >>>>>>> contain ?musl? in, say, HOTSPOT_BUILD_USER or whatever, so you?ll >>>>>>> probably want something more targeted for the check. Also, the >>>>>>> pattern used in other places in the file to convert the boolean to a >>>>>>> String seems to be ?" + p. >>>>>> Yes, converted the check into >>>>>> WhiteBox.getWhiteBox().getLibcName().contains("musl") - this >>>>>> should be >>>>>> more robust. >>>>>>> * exeinvoke.c >>>>>>> >>>>>>> I?m don?t know the "complicated interaction of signal handlers? well >>>>>>> enough to understand if the changes are correct, but assuming they >>>>>>> are: >>>>>>> >>>>>>> I?d feel better having the whole JDK1_1InitArgs jdk_args struct >>>>>>> initialized (memset). >>>>>>> >>>>>>> size_t stacksize seems to be unused. Perhaps get_java_stacksize >>>>>>> should return a size_t? >>>>>>> >>>>>>> I?d also remove the spaces between pthread_ and the argument list >>>>>>> while your at it (also pre-existing), not exactly obvious why only >>>>>>> the pthread_ calls have them.. >>>>>> This is addressed in the updated webrev. >>>>>>> * exestack-tls.c >>>>>>> >>>>>>> As a potential alternative, base the decision on a define set by the >>>>>>> build system (MUSL_LIBC). Just something to consider. What you have >>>>>>> should work. >>>>>> I'd suggest to keep it as is - there is no other precedent of this in >>>>>> tests to support altering the build system. >>>>>>> * TestTerminatedThread.java >>>>>>> >>>>>>> I don?t know where we stand on adding comments, but personally I?d >>>>>>> prefer a comment explaining why the test is excluded when running >>>>>>> with musl (not unlike the one you have in NativeLibraryTest.java). >>>>>> Fixed in the updated webrev. >>>>>>> * Test7029048.java >>>>>>> >>>>>>> Can VMProps::isMusl be reused? I?m assuming that moving the >>>>>>> predicate definition to TestHelper would require a slew of tests to >>>>>>> use -XX:+WhiteBox? >>>>>> Yes, this is exactly the problem we try to avoid here. Another >>>>>> option is >>>>>> to introduce another helper class just for these couple of tests, but >>>>>> there would be only a couple of places where it would be used. >>>>>>> Also, I know I looked at this before but don?t remember the >>>>>>> conclusion: why is the check at the end ?passed < expected? rather >>>>>>> than exact match - passed == expected? (pre-existing) >>>>>> The test was refactored upstream and does not have any magic >>>>>> numbers any >>>>>> more [4]. The webrev is updated. >>>>>>> Finally a question: What level of testing have you done of this and >>>>>>> on which versions of Alpine/?? >>>>>> JTReg, VM TestBase on all platforms (Linux x86_64, Linux x86, Linux >>>>>> Arm, >>>>>> Linux AArch64, Linux PPC, Windows x86_64, Windows x86, Mac) with no >>>>>> regressions. A downport of these changes to 14 passes JCK 14 on these >>>>>> platforms. >>>>>> >>>>>> The port was tested on Alpine 3.8 and 3.11 with JTReg, VM TestBase. >>>>>> With >>>>>> the exception of the issues listed above and SA which is not >>>>>> supported >>>>>> as per the JEP, there are no differences with Linux x86_64. A >>>>>> downport >>>>>> of these changes to 14 passes JCK 14 on Alpine Linux. >>>>>> >>>>>> -Aleksei >>>>>> >>>>>> [1]?https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/05/28/5__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdsgKGnV3w$? >>>>>> [2]?https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/05/25/3__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdsp8FgoM5$? >>>>>> [3]?https://urldefense.com/v3/__https://www.openwall.com/lists/musl/2020/02/12/9__;!!GqivPVa7Brio!K8peFNtteharrQnXwV5YhpYsiJtL-HbWoMKdVWr-YmE3act6PtOfcOS_ALXdstJH5-RH$? >>>>>> [4]?http://hg.openjdk.java.net/jdk/jdk/rev/57e7f837e6d9 >>>>>>> Cheers, >>>>>>> Mikael >>>>>>> >>>>>>>> Thanks, >>>>>>>> -Aleksei >>>>>>>> >>>>>>>> [1]?https://openjdk.java.net/jeps/386 >>>>>>>> [2]?http://cr.openjdk.java.net/~avoitylov/webrev.8247589 >>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-8247589) >>>>>>>> [3]?http://cr.openjdk.java.net/~avoitylov/webrev.portola >>>>>>>> [4]?https://bugs.openjdk.java.net/browse/JDK-8239450 >