guile-devel
[Top][All Lists]
Advanced

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

Re: GC + Java finalization


From: Jonas Hahnfeld
Subject: Re: GC + Java finalization
Date: Fri, 19 Nov 2021 15:52:02 +0100
User-agent: Evolution 3.42.1

Am Freitag, dem 19.11.2021 um 14:14 +0000 schrieb Maxime Devos:
> 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.

Any memory allocation through gc implicitly registers the memory. Both
changes are unrelated to finalization, they are there to avoid this
unnecessary registration. My previous replies only tried to clarify why
any other solution is worse.

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?

Jonas

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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