[RFC] Proposal to backport JEP 386 (Alpine Linux Port) to 11u

Thu Feb 24 13:49:34 UTC 2022

Thank you Thomas!

By now we've heard from most of the parties, and all the concerns are
addressed. Let me give another two working days for anyone to ask more
questions and raise concerns, at which point I'm going to start
proposing backports using the regular 11u process.

-Aleksei

On 24/02/2022 16:15, Thomas Stüfe wrote:
> Hi Alexei,
>
> On Thu, Feb 24, 2022 at 1:56 PM Aleksei Voitylov
> <aleksei.voitylov at bell-sw.com <mailto:aleksei.voitylov at bell-sw.com>>
> wrote:
>
>     Hi Thomas,
>
>     see inline:
>
>     On 23/02/2022 21:18, Thomas Stüfe wrote:
>>     Hi Alexei,
>>
>>     I think this makes sense and is probably less risky than
>>     backporting JEP 388 and JEP 391. Thanks for doing the work, this
>>     looks well prepared for review already.
>>
>>     I have some questions, which had not been immediately clear from
>>     the mail. I may be just slow.
>>
>>     - Did you have to make 11u specific changes to the individual
>>     backports? If yes, what and why?
>     Speaking of product code changes, all changes that had to be done
>     for 11u are cosmetic, it's mostly lines layout that had to be
>     taken care of. 8252248 is slightly different because of Solaris
>     support in 11u, but these changes are under #ifdefs in
>     libnio/ch/NativeThread.c.
>>     - are there changes to the glibc variant in 11u, and if yes, why?
>>     In other words, will anything change for the existing platforms?
>>     Because theoretically, nothing should, right? I see the change to
>>     isnan, is that motivated to just applying the upstream patch
>>     without change, or was there a deeper reason?
>
>     Yes, there are changes to glibc variant in 11u which are limited
>     to 100 lines of code. Most of the work done for Alpine Linux
>     support was actually cleanup to linux code. My take with the 11u
>     backport is to keep it simple and in line with what was
>     contributed to 16 to simplify maintenance. Let me break down the
>     changes en large so you can also do the risk assessment
>
>     - 8245938 removes dead code (also dead in 11u)
>     - 8252248 glibc-private  __SIGRTMAX is replaced with public
>     standard SIGRTMAX
>     - 8252250 isnan change analysis can be found in
>     https://bugs.openjdk.java.net/browse/JDK-8178689 comments
>     - 8247589 First, this change uses libnuma2 if available with
>     fallback to libnuma if libnuma2 is not found. Second, mmap and
>     mprotect are called at VM initialization to enable JDK to work on
>     systems with PaX grsecurity. No new API is used in terms of
>     libc/glibc compatibility level. Both changes are not specific to
>     Alpine (aside from the fact that Alpine enables it by default).
>
>
> Seems all reasonable. Thanks for breaking it down for me. 
>
> I agree that keeping the code aligned with mainline is worth these
> minor behavioral changes.
>
> Thanks, Thomas
>
>     Thanks,
>
>     -Aleksei
>
>>
>>     Thank you!
>>
>>     Thomas
>>
>>
>>     On Thu, Feb 17, 2022 at 3:12 PM Aleksei Voitylov
>>     <aleksei.voitylov at bell-sw.com
>>     <mailto:aleksei.voitylov at bell-sw.com>> wrote:
>>
>>         Hi,
>>
>>         Following recent backports of JEP 388 (Windows/AArch64 Port)
>>         and JEP 391
>>         (macOS/AArch64 Port), I’d like to propose a backport of JEP
>>         386 (Alpine
>>         Linux Port) [1] to OpenJDK 11u. Support for this port was
>>         baked in the
>>         Portola project and integrated into OpenJDK 16.
>>
>>         Motivation for 11u backport: the importance of this platform is
>>         explained by wide adoption of Alpine Linux in container
>>         environments
>>         [2]. Several OpenJDK vendors (Liberica, Corretto, Zulu)
>>         include patches
>>         that enable Alpine/MUSL for 11u and 8u for quite some time,
>>         without any
>>         issues. Others (MS) have recently added it. In our case the
>>         user demand
>>         for Alpine/musl support for both 11u and 8u was at least as
>>         strong as
>>         Mac/AArch64 and Windows/AArch64, I’d also like to hear if
>>         other OpenJDK
>>         vendors share our view of the importance of this platform in 11u.
>>
>>         The set of JBS issues required to be backported for
>>         Alpine/MUSL support
>>         in 11u is:
>>
>>         JDK-8217340 Compilation failed: tools/launcher/Test7029048.java
>>         -    Test-only fix
>>         JDK-8247592 refactor test/jdk/tools/launcher/Test7029048.java
>>         -    Test-only fix
>>         JDK-8245938 Remove unused print_stack(void) method from
>>         XToolkit.c
>>         -    Code fix, removal of dead code, applies cleanly
>>         JDK-8252248 __SIGRTMAX is not declared in musl libc
>>         -    Code fix
>>         JDK-8252250 isnanf is obsolete
>>         -    Code fix, substitutes isnanf with isnan which was proven
>>         to be ok
>>         at least since GLIBC 2.8/GCC 4.6 on Linux and any reasonable LLVM
>>         version – see the discussion in JDK-8178689 for further details.
>>         JDK-8247589 Implementation of Alpine Linux/x64 Port
>>         -    The actual build and code changes that tidy up code for MUSL
>>         JDK-8247591 Document Alpine Linux build steps in OpenJDK
>>         build guide
>>         -    Docs only fix
>>
>>         All patches combined: +480 lines, -146 lines.
>>         All source code changes: +133 lines, -43 lines.
>>
>>         For risk assessment and preliminary examination of the 11u
>>         maintainers,
>>         the full patchset can be observed in [3], separate 11u
>>         backports can be
>>         found in [4]. I plan to submit the actual PRs for individual
>>         backports
>>         one by one unless I hear reasonable concerns from 11u
>>         maintainers on the
>>         proposed changes.
>>
>>         The patchset passes full JCK+jtreg set without any
>>         regressions to other
>>         platforms (Windows, Linux, Mac, Solaris), including non-Intel
>>         where
>>         applicable. During integration of JEP 386 SAP kindly verified
>>         that these
>>         changes do not break AIX/XLC.
>>
>>         On the maintenance side, BellSoft will be happy to support
>>         this platform
>>         in 11u. But I’ll equally happily share the burden with other
>>         OpenJDK
>>         vendors that currently support Alpine/MUSL.
>>
>>         Thanks,
>>         -Aleksei
>>
>>         [1] https://openjdk.java.net/jeps/386
>>         [2] https://hub.docker.com/_/alpine
>>         [3]
>>         https://github.com/voitylov/jdk11u-dev/compare/d6bf0d1e7dac4f4820e5c16ca14a162717b5818d..920d286d8da398797738fbfd1eaf02e1f887e306
>>         [4]
>>         8217340:
>>         https://github.com/voitylov/jdk11u-dev/commit/01542ba865c518c2b5d827d6c0b95488129b658a
>>         8247592:
>>         https://github.com/voitylov/jdk11u-dev/commit/48a1e49807cc189cd23c569f4b28f20282010ffd
>>         8245938:
>>         https://github.com/voitylov/jdk11u-dev/commit/3e41399c3471c6664302e6487d8003ecaff5e23a
>>         8252248:
>>         https://github.com/voitylov/jdk11u-dev/commit/bd2a506a2f44e7e2c9a0007f256e5c2288cfbe34
>>         8252250:
>>         https://github.com/voitylov/jdk11u-dev/commit/41b6b490fe60c640c90d9e594557215e669955cc
>>         8247589:
>>         https://github.com/voitylov/jdk11u-dev/commit/b0562ab5e2aa23f27803832f3854f0538f51b891
>>         8247591:
>>         https://github.com/voitylov/jdk11u-dev/commit/920d286d8da398797738fbfd1eaf02e1f887e306
>>
>>