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

--===============1198970174==
Content-Type: multipart/alternative; boundary=001a114f178eefb0640545f4f3b6

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

> we don't add blocks to the reclaim lists until all objects in them have
been marked

Which means that a mark phase has been run to completion, starting not only
from GC roots, but from all previously-marked objects?

On Fri, Jan 13, 2017 at 9:54 AM, Hans Boehm <[email protected]> wrote:

> 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
>>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
> _______________________________________________
> bdwgc mailing list
> [email protected]
> https://lists.opendylan.org/mailman/listinfo/bdwgc
>

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

<div dir=3D"ltr">&gt;=C2=A0we don&#39;t add blocks to the reclaim lists unt=
il all objects in them have been marked<div><br></div><div>Which means that=
 a mark phase has been run to completion, starting not only from GC roots, =
but from all previously-marked objects?</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Fri, Jan 13, 2017 at 9:54 AM, Hans Boe=
hm <span dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">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 se=
t in the blocks still being reclaimed because we haven&#39;t allocated in t=
hem 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&#3=
9;t clear any mark bits as part of collection while blocks are still waitin=
g to be reclaimed, and that we don&#39;t add blocks to the reclaim lists un=
til all objects in them have been marked.<div><br></div><div>Hans</div></di=
v><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"mailto:i=
vmai-JGs/[email protected]" target=3D"_blank">ivmai-JGs/[email protected]</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc 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_bloc<wbr>k<br><=
br>Regards,<br>Ivan<span class=3D"HOEnZb"><font color=3D"#888888"><br></fon=
t></span></div><span class=3D"HOEnZb"><font color=3D"#888888">
</font></span></blockquote></div><span class=3D"HOEnZb"><font color=3D"#888=
888"><br></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888"=
>
<br>--=20
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href=3D"http://www.mailscanner.info/" target=3D"_blank"><b>MailScanner</=
b></a>, and is
<br>believed to be clean.

</font></span><br>______________________________<wbr>_________________<br>
bdwgc mailing list<br>
<a href=3D"mailto:[email protected]">[email protected]</a><=
br>
<a href=3D"https://lists.opendylan.org/mailman/listinfo/bdwgc" rel=3D"noref=
errer" target=3D"_blank">https://lists.opendylan.org/<wbr>mailman/listinfo/=
bdwgc</a><br></blockquote></div><br></div>

--001a114f178eefb0640545f4f3b6--

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