Re: GC + Java finalization

[Maxime Devos <maximedevos@telenet.be>]

Jonas Hahnfeld schreef op vr 19-11-2021 om 14:55 [+0100]:
> Am Freitag, dem 19.11.2021 um 13:48 +0000 schrieb Maxime Devos:
> > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > -  rx = scm_gc_malloc_pointerless (sizeof (regex_t),
> > > > > "regex");
> > > > > +  rx = scm_malloc (sizeof (regex_t));
> > > > 
> > > > If the regex why scm_gc_malloc_pointerless -> scm_malloc?
> > > > Is rx not pointerless?
> > > 
> > > Not sure I understand the question. We don't know what contents
> > > libc
> > > will write into regex_t. It could be pointers which would be bad
> > > for
> > > the garbage collector.
> > 
> > OK, if that's the case, seems like a bug in the original code, not
> > related to Java-style finalisation, so I would do that in a
> > separate
> > patch.

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.

Greetings,
Maxime