emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/igc: Implications of MPS being asynchronous


From: Stefan Kangas
Subject: Re: scratch/igc: Implications of MPS being asynchronous
Date: Sun, 12 Jan 2025 16:55:54 +0000

Eli Zaretskii <eliz@gnu.org> writes:

>> +With the traditional GC, you can also explicitly trigger a full GC, by
>> +calling the function =garbage-collect=.  With IGC, this is no longer the
>> +case, though that function does still perform some necessary internal
>> +cleanups.  The statistics returned by that function are also not
>> +accurate with IGC.
>
> Don't we have igc--colect?

That's true.

Should we perhaps make `garbage-collect` call `igc_collect`?  The user
did ask for a GC to happen, after all.

(IMHO, the code organization is a bit funny here, because
garbage_collect() doesn't do what it says on the tin.  I don't think
it's worth addressing that right now though.  Maybe it's worth taking a
second look after merging.)

diff --git a/src/alloc.c b/src/alloc.c
index 1db52350b2c..321ffcd9638 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7073,6 +7073,10 @@ DEFUN ("garbage-collect", Fgarbage_collect,
Sgarbage_collect, 0, 0, "",
   specpdl_ref count = SPECPDL_INDEX ();
   specbind (Qsymbols_with_pos_enabled, Qnil);
   garbage_collect ();
+#ifdef HAVE_MPS
+  /* With IGC, `garbage_collect' doesn't actually trigger GC.  */
+  igc_collect ();
+#endif
   unbind_to (count, Qnil);
   struct gcstat gcst = gcstat;



reply via email to

[Prev in Thread] Current Thread [Next in Thread]