Actually *T was not a good example to make my point, as we can start
debating about the GC walking the references and freeing the data pointed
to. However when you have []T, and you refer to some continuous buffer of
memory with some chunks [0:5] (gap) [50:100], etc there's not much benefit
of
On Thu, Mar 26, 2020 at 11:02 AM robfig wrote:
>
> RE reducing the capacity, I want to distinguish freeing the memory (1) used
> for the slice and (2) referred to by the slice elements. I can easily see
> that freeing (1) is hard and not so beneficial, but I can't see why (2) would
> be
I let you consider an example:
s := make([]*T, 100)
s1, s2, s3 := s[:50], s[50:], s[:]
( x lines of code)
s1 = s1[:5]
Would you like the GC to free the elements past the last s1 slice len? What
if s2, s3 are still used somewhere...
On Thursday, March 26, 2020 at 7:01:34 PM UTC+1, robfig
I see, thank you.
RE reducing the capacity, I want to distinguish freeing the memory (1) used
for the slice and (2) referred to by the slice elements. I can easily see
that freeing (1) is hard and not so beneficial, but I can't see why (2)
would be difficult, and the benefit seems potentially
By the way, I don't think your snippet shows what you think it's showing.
In particular, the output stays the same, even if you reduce the capacity
to 0: https://play.golang.org/p/r2YvnDNsoBg
I also always assumed the GC wouldn't do this optimization (throwing away
memory if it's past the capacity
On Thu, Mar 26, 2020 at 6:41 PM robfig wrote:
> Reducing a slice's length makes the elements unreachable, but the GC
> appears to still treat them as live, based on this snippet:
> https://play.golang.org/p/SvsE-nXi-JA
>
> I would have expected the HeapInUse to go down in the second measurement.
Reducing a slice's length makes the elements unreachable, but the GC
appears to still treat them as live, based on this snippet:
https://play.golang.org/p/SvsE-nXi-JA
I would have expected the HeapInUse to go down in the second measurement.
Why is that?
I presume that the GC is traversing
