unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Jonas Hahnfeld <hahnjo@hahnjo.de>, guile-devel@gnu.org
Subject: Re: GC + Java finalization
Date: Fri, 19 Nov 2021 18:48:13 +0000	[thread overview]
Message-ID: <98d5fd3f1735e9a04b7d06c0054240cc378cb528.camel@telenet.be> (raw)
In-Reply-To: <c2a5059becd3bf889143d163f3e1229db60c7d19.camel@hahnjo.de>

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 <https://www.hboehm.info/gc/#details>
or <https://www.hboehm.info/gc/faq.html>.  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
(<https://lists.gnu.org/archive/html/guile-devel/2021-07/msg00002.html>)
that I'm not a guile dev.

Greetings,
Maxime.




  reply	other threads:[~2021-11-19 18:48 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 12:05 GC + Java finalization Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-07-03 17:14 ` Maxime Devos
2021-07-03 17:26   ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-07-03 18:49     ` Maxime Devos
2021-07-03 18:54     ` Maxime Devos
2021-07-15 18:44 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-10-10 16:22   ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 12:18     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2022-02-22 10:14       ` Dr. Arne Babenhauserheide
2022-02-22 15:12         ` Mike Gran
2021-11-19 13:13   ` Maxime Devos
2021-11-19 13:32     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:35       ` Maxime Devos
2021-11-19 13:40         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:44           ` Maxime Devos
2021-11-19 13:53             ` Maxime Devos
2021-11-19 13:53             ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:01               ` Maxime Devos
2021-11-19 13:48       ` Maxime Devos
2021-11-19 13:55         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:14           ` Maxime Devos
2021-11-19 14:52             ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 18:48               ` Maxime Devos [this message]
2021-11-19 19:01                 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:15   ` Maxime Devos
2021-11-19 13:35     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:21       ` Maxime Devos
2021-11-19 15:32         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:17   ` Maxime Devos
2021-11-19 13:38     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-20  9:19   ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98d5fd3f1735e9a04b7d06c0054240cc378cb528.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-devel@gnu.org \
    --cc=hahnjo@hahnjo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).