Re: Next steps for igc feature branch

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: spwhitton@spwhitton.name,  emacs-devel@gnu.org,  pipcet@protonmail.com,
>>   jcm@SDF.ORG,  eller.helmut@gmail.com,  gerd.moellmann@gmail.com
>> Date: Sun, 27 Apr 2025 16:55:33 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >>
>> >> >  . Some platforms aren't supported by MPS.  We need to decide what to
>> >> >    do about that.
>> >>
>> >> Yes, but isn't this a smaller problem?
>> >
>> > Smaller as compared to what?
>> >
>> > We could decide that we drop support for those systems which MPS
>> > doesn't support.  Or we could decide that we will work on adapting MPS
>> > to those systems.  Or we could decide that the old GC will stay with
>> > us forever, in parallel with MPS-based igc.  Each one of these
>> > decisions has significant impact on what to do with the branch and
>> > whether we should do it before or after the merge.
>>
>> Apologies for my terse phrasing, and please allow me to clarify:
>> I meant a smaller problem than deciding whether to merge to master.
>>
>> I'd implicitly assumed that the old GC, which works everywhere,
>> would be kept in parallel, in a kind of staggered rollout of IGC, for
>> many years.
>> Then it becomes, possibly, eventually deprecated, over a long time.
>>
>> Given the IGC branch already works on a GNU system (with the kernel
>> Linux) -- presumably our primary target -- and indeed on other platforms as
>> reported by authors of IGC as well as testers, this partial yet
>> substantial coverage may be enough to consider landing to master.
>>
>>
>> So from a user point of view, we have the additional, optional build option
>> ./configure --with-igc=yes
>> This could become an optional option on master that 'works where it
>> works', similar to other options like GTK or Lucid, etc..
>
> What you say might make sense for an optional feature that is not too
> important.  But this is not that case, AFAIU: we want igc to become
> our main, if not the only, GC.  So from where I stand the problems I
> mentioned need to be figured out in advance.

I don't think that we need to decide anytime soon whether the current GC
eventually needs to be removed.  But, if we do, we should have another
look at the "ANSI C" build of MPS, which has no memory barriers and no
threads.

MPS without memory barriers seems like a very attractive option to me:
on most systems, it should just work (as it does on FreeDOS with the
DJGPP build), and I don't think there's a fundamental reason for
performance to be much worse than what alloc.c offers now: MPS allows
for mark-and-sweep pools as well as copying pools, so we can use the
former on systems where it is better not to copy.

The lack of threads is inconvenient, but adding thread support isn't as
hard as adding memory barriers, and doesn't require a standard MMU or
anything like that, so I think it's possible that we can make MPS work
on all interesting systems that way.

If Android starts using memory protection for its JVM in a way that
breaks MPS, or there are problems with Solaris that require debugging
(it seems unlikely that the GDB bug which prevents memory barriers from
working when debugging will ever be fixed), or we need to quickly add
support for a newly-accessible OS (iOS?), I think MPS without memory
barriers would still be a good option.

If the ANSI C build turns out not to be usable, and we can't fix it, we
should keep the alloc.c GC.

Pip