It can get expensive to do that. Instead of just a mark bit per object, and
a queue of pointers to mark, you need a mark bit per word and a queue of
ptr+len. You can also end up doing more than constant work per mark.
x := [10]*int{ ... 10 pointers ... }
a := x[:3:3]
b := x[7::]
x is now dead, but a and b are live. GC needs to scan a[0:3] and a[7:10].
What about a[3:7]?
x := [10]*int{ ... 10 pointers ... }
a1 := x[:1:1]
a2 := x[:2:2]
a3 := x[:3:3]
...
a10 := x[:10:10]
If the GC encounters the references in order a1, a2, ... , a10, then at
each step it has to scan one more word of x. Using just a mark bit per
word, it will end up taking quadratic time to process these references.
On Mon, Jan 13, 2020 at 3:17 AM Jan Mercl <0xj...@gmail.com> wrote:
> On Sat, Jan 11, 2020 at 4:43 AM <keith.rand...@gmail.com> wrote:
>
> >> But there's one guarantee - the "dead" slice portion after
> >> cap will not be scanned by the collector if no other live object uses
> >> it.
> >
> >
> > That's not correct. If there is a reference to an object, the entire
> object is live and is scanned, regardless of what the reference(s) looks
> like (ptr, slice with small cap, slice with large cap).
> > Again, this isn't in the spec - in principle the GC could not scan past
> the largest capacity. But we don't currently do that.
>
> Might be a low hanging optimization opportunity. But proving no other
> references exist is possibly the blocking issue.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CA%2BZMcOP-j%3DFtcSAbG4xpGjPv%2Bqt5wieo0Q%3DPOh3gp3Fa-HTiow%40mail.gmail.com.
