Re: [Gc] using a lot of finalizers?

--===============0163660861==
Content-Type: multipart/alternative; boundary=001a114c08f494cec60533a75be8

--001a114c08f494cec60533a75be8
Content-Type: text/plain; charset=UTF-8

Hi Basile,

There is no big scaling problem with having huge numbers of objects with
finalizers.

There is a hash table holding a reference to each object with a finalizer.
The table is grown as necessary, but access will remain O(1).

On each GC, every object in the hash table is walked to see whether it was
unreachable and needs finalizing. This is O(n) on the number of objects
with finalizers. The rest of the gc work is generally O(n) on the number of
reachable objects.

Objects with finalizers require two GC cycles to be collected. The
finalizer is run on the first GC, and the finalizer forgotten. On the 2nd
GC the object will (usually) be a normal unreachable object and be
collected.

But the question that must be asked is: WHY do you want so many finalizers?
What will they do? This is usually a sign of a bad design. Finalizers
should usually be associated with resources external to the program: files,
or network ports, or GUI windows or the like.


On Wed, May 25, 2016 at 11:20 AM, Basile Starynkevitch <
[email protected]> wrote:

> Hello,
>
> In my MELT monitor (see https://github.com/bstarynk/melt-monitor-2015/
> for details) I am having a lot finalizers. You might consider (GC-wise)
> that it is sort-of some Lisp (but multi-threaded, with a small thread pool
> of about half a dozen threads) interpreter.
>
> Basically, I have (conceptually) a lot of immutable GC-ed values
> (allocated with GC_MALLOC) and some mutable GC-ed "items" (also allocated
> with GC_MALLOC). Those items are registering a finalizer with
> GC_REGISTER_FINALIZER_IGNORE_SELF at creation time.
>
> In the event I would have a large (e.g. a dozen of gigabytes) GC heap, is
> it acceptable to have many (e.g. half a million) of items with finalizers
> and much more (e.g. several millions) values.
>
> So my question becomes: can I have many items, each having registered a
> finalizer, or is it not acceptable performance-wise?
>
> Or should I put a lot of design effort to avoid finalizers?
>
> My blind guess is that since "gc/gc_cpp.h" is using
> GC_REGISTER_FINALIZER_IGNORE_SELF it should be acceptable to have a lot of
> finalizers.
>
> Regards.
>
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

--001a114c08f494cec60533a75be8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Basile,<div><br></div><div>There is no big scaling prob=
lem with having huge numbers of objects with finalizers.</div><div><br></di=
v><div>There is a hash table holding a reference to each object with a fina=
lizer. The table is grown as necessary, but access will remain O(1).</div><=
div><br></div><div>On each GC, every object in the hash table is walked to =
see whether it was unreachable and needs finalizing. This is O(n) on the nu=
mber of objects with finalizers. The rest of the gc work is generally O(n) =
on the number of reachable objects.</div><div><br></div><div>Objects with f=
inalizers require two GC cycles to be collected. The finalizer is run on th=
e first GC, and the finalizer forgotten. On the 2nd GC the object will (usu=
ally) be a normal unreachable object and be collected.</div><div><br></div>=
<div>But the question that must be asked is: WHY do you want so many finali=
zers? What will they do? This is usually a sign of a bad design. Finalizers=
 should usually be associated with resources external to the program: files=
, or network ports, or GUI windows or the like.</div><div><br></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May 25, 20=
16 at 11:20 AM, Basile Starynkevitch <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
In my MELT monitor (see <a href=3D"https://github.com/bstarynk/melt-monitor=
-2015/" rel=3D"noreferrer" target=3D"_blank">https://github.com/bstarynk/me=
lt-monitor-2015/</a> for details) I am having a lot finalizers. You might c=
onsider (GC-wise) that it is sort-of some Lisp (but multi-threaded, with a =
small thread pool of about half a dozen threads) interpreter.<br>
<br>
Basically, I have (conceptually) a lot of immutable GC-ed values (allocated=
 with GC_MALLOC) and some mutable GC-ed &quot;items&quot; (also allocated w=
ith GC_MALLOC). Those items are registering a finalizer with GC_REGISTER_FI=
NALIZER_IGNORE_SELF at creation time.<br>
<br>
In the event I would have a large (e.g. a dozen of gigabytes) GC heap, is i=
t acceptable to have many (e.g. half a million) of items with finalizers an=
d much more (e.g. several millions) values.<br>
<br>
So my question becomes: can I have many items, each having registered a fin=
alizer, or is it not acceptable performance-wise?<br>
<br>
Or should I put a lot of design effort to avoid finalizers?<br>
<br>
My blind guess is that since &quot;gc/gc_cpp.h&quot; is using GC_REGISTER_F=
INALIZER_IGNORE_SELF it should be acceptable to have a lot of finalizers.<b=
r>
<br>
Regards.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
Basile STARYNKEVITCH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"http://sta=
rynkevitch.net/Basile/" rel=3D"noreferrer" target=3D"_blank">http://starynk=
evitch.net/Basile/</a><br>
email: basile&lt;at&gt;starynkevitch&lt;dot&gt;net mobile: +33 6 8501 2359<=
br>
8, rue de la Faiencerie, 92340 Bourg La Reine, France<br>
*** opinions {are only mine, sont seulement les miennes} ***<br>
_______________________________________________<br>
bdwgc mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">bdwgc@lists.=
opendylan.org</a><br>
<a href=3D"https://lists.opendylan.org/mailman/listinfo/bdwgc" rel=3D"noref=
errer" target=3D"_blank">https://lists.opendylan.org/mailman/listinfo/bdwgc=
</a><br>
<br>
-- <br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.<br>
<br>
</font></span></blockquote></div><br></div>

--001a114c08f494cec60533a75be8--

--===============0163660861==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc
--===============0163660861==--