Re: [Gc] Collect a little and continue reclaim in a loop: possible?

Hans Boehm <[email protected]> Thu, 12 Jan 2017 22:54:31 -0800
Newsgroups gmane.comp.programming.garbage-collection.boehmgc
Message-ID <CAPUmR1ZM3MaEg-nFhXT2FUv0UzbfAEdk=F-9v7akPW-a78hwPg@mail.gmail.com>
--===============0808358862==
Content-Type: multipart/alternative; boundary=001a1144883054d6500545f44e25

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

I think this is fine. Once we finish a GC cycle, we put blocks waiting to
be swept on the reclaim lists. We can start another incremental GC without
completely finishing the last sweep. No mark bits should get set in the
blocks still being reclaimed because we haven't allocated in them since the
last cycle. So nothing can become newly reachable (except as a result of
misidentified pointers). We do need to make sure that we don't clear any
mark bits as part of collection while blocks are still waiting to be
reclaimed, and that we don't add blocks to the reclaim lists until all
objects in them have been marked.

Hans

On Wed, Jan 11, 2017 at 11:51 AM, Ivan Maidanski <ivmai-JGs/[email protected]> wrote:

> Hello Hans,
>
> Looking into GC_allocobj, it has the following:
>     while (*flh == 0) {
>       ENTER_GC();
>       /* Do our share of marking work */
>       if (TRUE_INCREMENTAL) GC_collect_a_little_inner(1); // calls
> GC_mark_some which, in turn, sets some mark bits
>       /* Sweep blocks for objects of this size */
>       GC_continue_reclaim(gran, kind); // reclaims some objects with unset
> mark bits
>       ...
>     }
>
> Is this ok to reclaim memory before finishing the collection?
>
> I have added the assertions to reclaim.c functions which examine mark bits
> (see the attachment), and do gctest on linux/x64 as follows:
> gcc -I include -DGC_ASSERTIONS  -DGC_TIME_LIMIT=1 -DGC_THREADS -I
> libatomic_ops/src tests/test.c extra/gc.c -lpthread -ldl
> ./a.out
> Switched to incremental mode
> Emulating dirty bits with mprotect/signals
> Assertion failure: extra/../reclaim.c:335 // GC_allocobj ->
> GC_continue_reclaim -> GC_reclaim_small_nonempty_block
>
> Regards,
> Ivan
>

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

<div dir=3D"ltr">I think this is fine. Once we finish a GC cycle, we put bl=
ocks waiting to be swept on the reclaim lists. We can start another increme=
ntal GC without completely finishing the last sweep. No mark bits should ge=
t set in the blocks still being reclaimed because we haven&#39;t allocated =
in them since the last cycle. So nothing can become newly reachable (except=
 as a result of misidentified pointers). We do need to make sure that we do=
n&#39;t clear any mark bits as part of collection while blocks are still wa=
iting to be reclaimed, and that we don&#39;t add blocks to the reclaim list=
s until all objects in them have been marked.<div><br></div><div>Hans</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jan=
 11, 2017 at 11:51 AM, Ivan Maidanski <span dir=3D"ltr">&lt;<a href=3D"mail=
to:ivmai-JGs/[email protected]" target=3D"_blank">ivmai-JGs/[email protected]</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div>Hello Hans,<br><br>Looking into GC_allocobj, it has the following:<br>=
=C2=A0=C2=A0=C2=A0 while (*flh =3D=3D 0) {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ENTER_GC();<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Do our share of markin=
g work */<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (TRUE_INCREMENTAL) GC_collec=
t_a_little_inner(1); // calls GC_mark_some which, in turn, sets some mark b=
its<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /* Sweep blocks for objects of this s=
ize */<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GC_continue_reclaim(gran, kind); /=
/ reclaims some objects with unset mark bits<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 ...<br>=C2=A0=C2=A0=C2=A0 }<br><br>Is this ok to reclaim memory before =
finishing the collection?<br><br>I have added the assertions to reclaim.c f=
unctions which examine mark bits (see the attachment), and do gctest on lin=
ux/x64 as follows:<br>gcc -I include -DGC_ASSERTIONS=C2=A0 -DGC_TIME_LIMIT=
=3D1 -DGC_THREADS -I libatomic_ops/src tests/test.c extra/gc.c -lpthread -l=
dl<br>./a.out<br>Switched to incremental mode<br>Emulating dirty bits with =
mprotect/signals<br>Assertion failure: extra/../reclaim.c:335 // GC_allocob=
j -&gt; GC_continue_reclaim -&gt; GC_reclaim_small_nonempty_<wbr>block<br><=
br>Regards,<br>Ivan<br></div>
</blockquote></div><br></div>

--001a1144883054d6500545f44e25--

--===============0808358862==
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
--===============0808358862==--