Am Freitag, dem 19.11.2021 um 18:48 +0000 schrieb Maxime Devos: > Jonas Hahnfeld schreef op vr 19-11-2021 om 15:52 [+0100]: > > Am Freitag, dem 19.11.2021 um 14:14 +0000 schrieb Maxime Devos: > > > [...] > > > > > > From your other responses, I now know it is actually related to > > > (non- > > > )Java style finalisation, but my comment about ‘separate patch’ > > > still > > > seems to apply: > > > > > > > > > > > Again, as replied in July to the same comment, it *is* a separate > > > > patch for exactly this reason. > > > > > > More concretely, it is in the same patch as that modified > > > libguile/random.c.  The patch to libguile/random.c doesn't seem to > > > be for non-Java finalization reasons. Going by the commit message, > > > the only possible reason I could find is: > > > > > > ‘There is no point in registering memory with the garbage collector > > > if it doesn't need to do its job’ > > > > > > But I don't see any ‘registering memory’, only replacing > > > scm_gc_calloc+scm_gc_free by scm_calloc+free, and without any > > > finalisation in sight. Unless you mean with ‘registering memory’ > > > the "random bignum chunks" argument. But that still seems unrelated > > > to non-Java finalization. > > > > Any memory allocation through gc implicitly registers the memory. > > I don't mean what you mean with ‘registering memory’. I don't > see that phrase anywhere at > or . I only know about > registering finalisers, but not about registering memory. Maybe it's not an official term; I call it "registration" because the garbage collector has to keep track of all memory segments it handed out, so it "registers" the allocation in a data structure somewhere. > Also, I'm not sure what you are trying to say here and in the following > paragraph. Is this some kind of argument for why the change to > libguile/random.c should be in the same patch, or general explanation, > ...? Both changes address the same issue of removing matching calls to scm_gc_alloc+scm_gc_free. That's why I think it's one logical change, even though one is actually a problem when disabling Java-style finalization - it makes sense even without the following patch. > > > Both changes are unrelated to finalization, they are there to avoid this > > unnecessary registration. > Thanks for the clarification, though I have no idea what ‘registration’ > is ... > > My previous replies only tried to clarify why > > any other solution is worse. > > ... but what problem and what replies are you referring to here? > I haven't seen any e-mails explaining GC problems in libguile/random.c. > I only have seen replies about non-Java style finalisation, which > do not apply to libguile/random.c (no objects but the stack have a > reference to random_chunks anywhere and libguile/random.c is not > playing with finalizers). Yes, the one in libguile/random.c is just unnecessary, probably not actually a problem. Jonas