[Top][All Lists]

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

Re: GC + Java finalization

From: Maxime Devos
Subject: Re: GC + Java finalization
Date: Fri, 19 Nov 2021 18:48:13 +0000
User-agent: Evolution 3.38.3-1

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.

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 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).

> Another question: Do you actually have permission to apply my
> patches?
> You already reviewed my patches in July, but as they weren't applied
> back then, does this mean we need somebody else to actually get them
> in?

No, I don't have commit access. I noted in July
that I'm not a guile dev.


reply via email to

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