Subject: bug#54698: closed (Re: bug#54698: non-recursive GC marking [PATCH])

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 04 Apr 2022 17:19:02 +0000

Your bug report

#54698: non-recursive GC marking [PATCH]

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
54698: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=54698
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#54698: non-recursive GC marking [PATCH]
From: Mattias Engdegård <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: Lars Ingebrigtsen <[email-masked]>, [email-masked]
Date: Mon, 4 Apr 2022 19:18:31 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

4 apr. 2022 kl. 14.25 skrev Eli Zaretskii <[email-masked]>:

> I don't need to prove you wrong: if the problem is real, we will hear
> about that soon enough.

Yes, you are probably right about that.

4 apr. 2022 kl. 13.31 skrev Lars Ingebrigtsen <[email-masked]>:

> (bug#31362 and bug#46900 should probably be closed after applying this
> patch, I guess.)

Thanks, will do.

Pushed to master (after tidying up).

Subject: non-recursive GC marking [PATCH]
From: Mattias Engdegård <[email-masked]>
To: [email-masked]
Date: Sun, 3 Apr 2022 20:40:57 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

The GC uses recursion to traverse data structures for marking which imposes a limit to how big (or deeply nested) Lisp data structures can be, and usually results in an immediate Emacs crash without warning when that limit is exceeded.

The attached patch replaces recursion with an explicit stack for most common object types: conses, vectors, records, hash tables, symbols, functions etc. Recursion remains for some less common types (buffers, frames etc) but these are typically not used in quantities to cause a problem.

A side benefit is that GC becomes quite a bit faster as a result. Actual workloads such as byte-compilation are consequently sped up by a small but measurable amount.

The patch is explicitly unfinished in some uninteresting respects to make it easier to read; `process_mark_stack` needs reindenting.