From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library" Newsgroups: gmane.lisp.guile.devel Subject: Re: GC + Java finalization Date: Fri, 19 Nov 2021 20:01:55 +0100 Message-ID: <241b7e993d1d30a1fde808145024f13802ed4553.camel@hahnjo.de> References: <9ce77d5e08d50456eddc575179b68ac17afc9bf6.camel@hahnjo.de> <1cc3648e5196bf23023ec7a0ab95a9ad46f8554c.camel@telenet.be> <497caf03e995dd3cad9df748a2e5e7e5e8a245eb.camel@telenet.be> <5f9eec1969de97273cb0c335587ba98080225f6e.camel@hahnjo.de> <98d5fd3f1735e9a04b7d06c0054240cc378cb528.camel@telenet.be> Reply-To: Jonas Hahnfeld Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-aIfPB3OZwiLfrOBtkabM" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36168"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.42.1 To: Maxime Devos , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Nov 19 20:02:26 2021 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mo99W-0009DS-8B for guile-devel@m.gmane-mx.org; Fri, 19 Nov 2021 20:02:26 +0100 Original-Received: from localhost ([::1]:40476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo99U-0001pI-N4 for guile-devel@m.gmane-mx.org; Fri, 19 Nov 2021 14:02:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48590) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo99B-0001os-RB for guile-devel@gnu.org; Fri, 19 Nov 2021 14:02:05 -0500 Original-Received: from backus.hahnjo.de ([193.30.122.186]:49760 helo=mail.hahnjo.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo999-00068n-Md for guile-devel@gnu.org; Fri, 19 Nov 2021 14:02:05 -0500 Original-Received: from [IPv6:2001:16b8:1e92:200:6657:51b0:48f8:9366] (unknown [IPv6:2001:16b8:1e92:200:6657:51b0:48f8:9366]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hahnjo.de (Postfix) with ESMTPSA id 76936542C017; Fri, 19 Nov 2021 20:02:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hahnjo.de; s=default; t=1637348520; bh=ONcWKrDFgtc2tBzlN6NlPSf5aSdecHyDf82aWiJJImQ=; h=Subject:From:To:Date:In-Reply-To:References; b=DRYxS0/eSDne0pqL9bIPIkGXx9su2ylXNstq+mbIEj6AdpiSVww93uYSZQyP7kkyU lOpF+0qWR1QQTSbLZVVynL0upd3GyfqzLEhwg5KRET618piHH7IH5S+cv//p7FrwO8 Wt8CWB2BT7vQPz39nrJbbeO/hkQdPcUmAg33m+0eduqO2sDVWlGrM0Y+JeVTY/0kic Samw1SL/jtoO7EH/y8cWK5PnS83H4L0jxnDu/d0BCLfeyi2FKmu0bvDHsnpMrj0IyJ Q+yQHGnD/0035fVO0qR6n+/+fYjgMxRI2kIOasN75yWPlNp56pgkiNk3IOsBShflAf uBvlaIu0JYNbg== In-Reply-To: <98d5fd3f1735e9a04b7d06c0054240cc378cb528.camel@telenet.be> Received-SPF: pass client-ip=193.30.122.186; envelope-from=hahnjo@hahnjo.de; helo=mail.hahnjo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20975 Archived-At: --=-aIfPB3OZwiLfrOBtkabM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: > > > [...] > > >=20 > > > From your other responses, I now know it is actually related to > > > (non- > > > )Java style finalisation, but my comment about =E2=80=98separate patc= h=E2=80=99 > > > still > > > seems to apply: > > >=20 > > > >=20 > > > > Again, as replied in July to the same comment, it *is* a separate > > > > patch for exactly this reason. > > >=20 > > > More concretely, it is in the same patch as that modified > > > libguile/random.c.=C2=A0 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: > > >=20 > > > =E2=80=98There is no point in registering memory with the garbage col= lector > > > if it doesn't need to do its job=E2=80=99 > > >=20 > > > But I don't see any =E2=80=98registering memory=E2=80=99, only replac= ing > > > scm_gc_calloc+scm_gc_free by scm_calloc+free, and without any > > > finalisation in sight. Unless you mean with =E2=80=98registering memo= ry=E2=80=99 > > > the "random bignum chunks" argument. But that still seems unrelated > > > to non-Java finalization. > >=20 > > Any memory allocation through gc implicitly registers the memory. >=20 > I don't mean what you mean with =E2=80=98registering memory=E2=80=99. I d= on'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. >=20 > > Both changes are unrelated to finalization, they are there to avoid thi= s > > unnecessary registration. > Thanks for the clarification, though I have no idea what =E2=80=98registr= ation=E2=80=99 > is ... > > My previous replies only tried to clarify why > > any other solution is worse. >=20 > ... 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 --=-aIfPB3OZwiLfrOBtkabM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEXw/5YGpL6H9VOgO2kcnDPSxhrNsFAmGX9KMACgkQkcnDPSxh rNtW4wgApUAxAwW+u9xk2K26N04p0TTmZhC4JfVlirba3AezbT7ykgSe3MbgtGRK l5XHDLFwlIbunL91tF23ogVo3g24WsMmPsHd2OjT2hJQBwgG3+9JL6VE7mwCJng4 e7NAhcsTStQnh460gxG7rma1HXbiz5He0jw/t5AJU1Ggd6B2yPwLr2sF6WfDu1i1 q3s9GTQX6wzEWw98yZ02q/XqaqjeFz1ZNx3pIEn6F+iIST0kD40/W/oATd6VQsP0 Qs1jxMfxDLaoKyMu8OXarxn4FBKRiSH3qdon91bn5aDey+TqAFVQCeDxIAULf3ua WONu7uHBdle5kswO0ao38xWlUCL4Bw== =zsGC -----END PGP SIGNATURE----- --=-aIfPB3OZwiLfrOBtkabM--