MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Wed, 22 Jun 2022 18:39:30 +0200
Message-Id: <CKWT7Z7BBSUI.2FVAM05ZUS5UO@sumire>
Cc: <~alpine/devel@lists.alpinelinux.org>
Subject: Re: Native Alpine GLibc support (NEW)
From: "alice" <alice@ayaya.dev>
To: "Tomas Kolda" <koldat@gmail.com>, "Ariadne Conill"
 <ariadne@dereferenced.org>
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com> <a3367d7-d3c5-4755-289e-37507033405f@dereferenced.org> <CAGFcrMmSG6RbG_O+NrHZ0Cys=6stLy59JjBsqd=BnfncLXdiCQ@mail.gmail.com>
In-Reply-To: <CAGFcrMmSG6RbG_O+NrHZ0Cys=6stLy59JjBsqd=BnfncLXdiCQ@mail.gmail.com>

On Wed Jun 22, 2022 at 2:04 PM CEST, Tomas Kolda wrote:
> > Yes, I have written about this before[0].  Mixing glibc and musl
> > environments will lead to instability -- this can be overcome with prop=
er
> > 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 thi=
ngs
> > 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 appro=
ve
> > this proposal because the project is already overwhelmed with work to d=
o.
> >
> 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