[prev in list] [next in list] [prev in thread] [next in thread]
List: sbcl-devel
Subject: Re: [Sbcl-devel] I'm missing something to do with card marks
From: Douglas Katzman via Sbcl-devel <sbcl-devel () lists ! sourceforge ! net>
Date: 2022-06-05 15:12:23
Message-ID: CAOrNasw1fmRr7ZmPoPJwz5_=REGjRFS6ktJF3JooLkg2TovQNA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
You could flip the order but it will be trickier to verify the marking
invariant which becomes something like: an unmarked card contains no
old->young pointer or else for each violation there is some interrupt
context that has a register pointing to the object with the old->young
pointer. It would have pushed a lot of complexity into the checker, and
then I would have probably wanted to implement a checker-checker to make
sure that verify_heap correctly understands the weaker invariant.
There's also a common refrain from a certain other school of thought: "but
safepoints can deal with that". Which is true except that our
implementation of safepoints is horrid.
Anway if you want to carry out the experiment and report back, I wouldn't
say no to it.
On Sun, Jun 5, 2022 at 6:38 AM Hayley Patton <hayley@applied-langua.ge>
wrote:
> Okay, it's handled by sticky_preserve_pointer, which forces cards
> referenced by roots to be dirty. I guess I'm still curious as to what
> would happen if the card mark was performed after the assignment; as a
> very similar issue would arise in a concurrent GC, as there is no
> synchronisation between mutators performing updates and the collector
> starting logging.
>
> On 5/6/22 16:35, Hayley Patton wrote:
> > A card is dirtied before a reference is actually stored, when SBCL
> > uses soft card marks. Couldn't triggering GC between storing a card
> > mark and storing the reference produce a old->new reference that isn't
> > reflected in card marks? Something like:
> >
> > Mutator: dirties a card
> > Collector: stops world for minor GC, checks cards, card doesn't (yet)
> > have old->new references so the card is cleaned
> > Mutator: stores old->new reference
> > Collector: stops world for minor GC, checks cards, the old->new
> > reference is on a clean card, so the reference is not updated/scavenged
> >
> > What prevents the dangling reference here? One solution I thought of
> > was to reverse the order of dirtying a card and storing a reference,
> > as the target of the update would still be scavenged (per
> > scavenge_pinned_ranges) if a collection occured just after storing the
> > reference, and so having an out-of-date card would not be a problem.
> > But SBCL does not do that.
> >
> >
> >
> > _______________________________________________
> > Sbcl-devel mailing list
> > Sbcl-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
>
>
>
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
[Attachment #5 (text/html)]
<div dir="ltr">You could flip the order but it will be trickier to verify the marking \
invariant which becomes something like: an unmarked card contains no old->young \
pointer or else for each violation there is some interrupt context that has a \
register pointing to the object with the old->young pointer. It would have pushed \
a lot of complexity into the checker, and then I would have probably wanted to \
implement a checker-checker to make sure that verify_heap correctly understands the \
weaker invariant.<div>There's also a common refrain from a certain other school \
of thought: "but safepoints can deal with that". Which is true except \
that our implementation of safepoints is horrid.</div><div>Anway if you want to carry \
out the experiment and report back, I wouldn't say no to it.</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 5, 2022 at 6:38 AM \
Hayley Patton <<a \
href="mailto:hayley@applied-langua.ge">hayley@applied-langua.ge</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Okay, it's handled \
by sticky_preserve_pointer, which forces cards <br> referenced by roots to be dirty. \
I guess I'm still curious as to what <br> would happen if the card mark was \
performed after the assignment; as a <br> very similar issue would arise in a \
concurrent GC, as there is no <br> synchronisation between mutators performing \
updates and the collector <br> starting logging.<br>
<br>
On 5/6/22 16:35, Hayley Patton wrote:<br>
> A card is dirtied before a reference is actually stored, when SBCL <br>
> uses soft card marks. Couldn't triggering GC between storing a card <br>
> mark and storing the reference produce a old->new reference that isn't \
<br> > reflected in card marks? Something like:<br>
><br>
> Mutator: dirties a card<br>
> Collector: stops world for minor GC, checks cards, card doesn't (yet) <br>
> have old->new references so the card is cleaned<br>
> Mutator: stores old->new reference<br>
> Collector: stops world for minor GC, checks cards, the old->new <br>
> reference is on a clean card, so the reference is not updated/scavenged<br>
><br>
> What prevents the dangling reference here? One solution I thought of <br>
> was to reverse the order of dirtying a card and storing a reference, <br>
> as the target of the update would still be scavenged (per <br>
> scavenge_pinned_ranges) if a collection occured just after storing the <br>
> reference, and so having an out-of-date card would not be a problem. <br>
> But SBCL does not do that.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> Sbcl-devel mailing list<br>
> <a href="mailto:Sbcl-devel@lists.sourceforge.net" \
target="_blank">Sbcl-devel@lists.sourceforge.net</a><br> > <a \
href="https://lists.sourceforge.net/lists/listinfo/sbcl-devel" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/sbcl-devel</a><br> <br>
<br>
<br>
<br>
_______________________________________________<br>
Sbcl-devel mailing list<br>
<a href="mailto:Sbcl-devel@lists.sourceforge.net" \
target="_blank">Sbcl-devel@lists.sourceforge.net</a><br> <a \
href="https://lists.sourceforge.net/lists/listinfo/sbcl-devel" rel="noreferrer" \
target="_blank">https://lists.sourceforge.net/lists/listinfo/sbcl-devel</a><br> \
</blockquote></div>
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic