Comment 2:

I am unable to reproduce this.  
Note that MemStats.Alloc is logged in the heap dump output, you don't need to log it
separately.  Just use d.Memstats.Alloc if d is a *read.Dump.
I get an MemStats.Alloc of 124MB.  There are only three objects in the dump with "ssa"
in their type name, and they are all ssa.Const.
There are a few objects in the dump which are unreachable.  I need to find out why that
is.  But they are all untyped (probably pointerless or runtime internal) and there are
only a few thousand of them using a total of 1MB.

Comment 3:

Ok, I figured out what these unreachable objects are.  They are the MSpan's types arrays
that are freed during sweeping.  Sweeping doesn't happen during runtime.GC() so the heap
dumper does it.  It is harmless and does not indicate an inconsistency between GC and
the dumper.
Maybe an explicit runtime.GC() should sweep as well as mark?  Something to think about.

Comment 4:

i agree. i think there are other issue about making explicit runtime.GC() run full mark
and sweep.

Comment 5:

CL https://golang.org/cl/89360043 mentions this issue.

Comment 6:

> Maybe an explicit runtime.GC() should sweep as well as mark?  Something to think about.
It already does. It triggers GC two times, two GCs necessary include full sweeping in
between.

Comment 7:

I see.  Then I don't understand how MSpan.types.data arrays are unreachable but not
collected after I do a runtime.GC().
In heapdump, I do:
    for(i = 0; i < runtime·mheap.nspan; i++) {
        s = runtime·mheap.allspans[i];
        if(s->state == MSpanInUse)
            runtime·MSpan_EnsureSwept(s);
    }
If I start a heap dump right after calling runtime.GC(), this loop triggers lots of
MSpans to get freed, leaving the type data arrays as garbage.  If runtime.GC() does 2
gcs, shouln't all that freeing have happened already?

Comment 8:

Or maybe we're just seeing remnants.  The first gc/sweep frees all the regular objects
and makes some type data arrays unreachable.  The second gc collects those type data
arrays.  If those objects were the last live objects in their MSpans, then more type
data arrays become unreachable after a second sweep.

Comment 9:

Types are freed during sweeping, so they would require 3 GCs. As you noted, this process
is actually transitive.

Comment 10:

This issue was updated by revision 29d1b21.

LGTM=rsc
R=rsc, dvyukov
CC=golang-codereviews
https://golang.org/cl/89360043

Comment 11:

This was probably partially fixed with CL 90440043, and the rest being the lingering
types data needing a few GCs to fully collect.

Status changed to Fixed.