MIME-Version: 1.0
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
 <a3367d7-d3c5-4755-289e-37507033405f@dereferenced.org>
In-Reply-To: <a3367d7-d3c5-4755-289e-37507033405f@dereferenced.org>
From: Tomas Kolda <koldat@gmail.com>
Date: Wed, 22 Jun 2022 14:04:12 +0200
Message-ID: <CAGFcrMmSG6RbG_O+NrHZ0Cys=6stLy59JjBsqd=BnfncLXdiCQ@mail.gmail.com>
Subject: Re: Native Alpine GLibc support (NEW)
To: Ariadne Conill <ariadne@dereferenced.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

> Yes, I have written about this before[0].  Mixing glibc and musl
> environments will lead to instability -- this can be overcome with proper
> multi-arch support, but we have not implemented this in Alpine yet (and
> apk-tools would need some minor changes to the solver to become
> multi-arch aware).
>
I know. That is why I want to have glibc build. Many JNI dependencies
in Java is glibc based for example. It is really hard to keep up.
>
> Locks in musl are done with atomics.  The advantage is probably due to the
> fact that glibc has lock elision, which musl does not yet have.
> Investigating the addition of lock elision to musl is on my list of things
> to do eventually.
>
> Which JVM are you using?  OpenJDK 17 and later have their own internal
> implementation of lock elision for Java/JNI locks, which should improve
> performance.
>
I tried JDK 8, 11, 17. Latest versions. No difference. Yes it is in
futex as you said. From user perspective it matters, because it is 5
times slower. As I said I do not believe MUSL can dramatically change
pthread implementation as it is most sensitive part and very hard to
test. It is very long run.

> - customize hundreds of APKBUILDs which will require the cooperation of
> package maintainers (who may be skeptical)
I do not agree with this. Most changes in that 300 set was in the
basic packages that was requiring MUSL tweaks. There will be less
tweaks after we will go further as more complex applications are using
libraries that are solved already. Anyway even from statistical
perspective it is 17 changes for 300 packages -> 5-6%. I am not sure
how many packages are in Alpine, but we can extrapolate.

I also do not agree that someone would just for one "if" be pushing
change out. There are many patches for all other reasons. I am
positive that people tend to help others. And this change does not
generate any work for them if they will not need to support it. They
will just try to keep it in working way.
>
> Speaking in personal capacity, I do not think the Alpine TSC will approve
> this proposal because the project is already overwhelmed with work to do.
>
Agree. I think that for start it would be great to at least allow "if"
patches to be able to merge it. It will be noop for Alpine.

See example changes here:
https://github.com/koldat/alpine/pull/1