restore type cache pruning in sysimage saving

[JeffBezanson]

The code for this had bitrotted --- dump.c initializes builtin_typenames but doesn't use it, and staticdata.c uses it but doesn't initialize it 😂 This makes it do something again. I noticed this when looking into tree shaking, and in the future it will be very useful for that, to avoid spurious references to things that could otherwise be removed.

[JeffBezanson]

Hmm, how do we convince the gc analyzer that the system image shenanigans are ok? The errors don't obviously point to changes in this PR so it makes me wonder how it worked before.

[yuyichao]

Aren't all of these running with GC disabled?

[JeffBezanson]

Yes.

[yuyichao]

So it seems that JL_GC_DISABLED should fix it, though I have no idea why this wasn't detected as an error before. The control flow and the arguments leading to the error also seems unchanged...

[vtjnash]

Might be simpler to just NULL the references now (in a copy of the svec) then save/restore the ->cache fields, instead of removing them and needing to mess with them on startup too?

[JeffBezanson]

How exactly would that work? How do we know which entries to NULL if the ->cache fields are also saved?

[vtjnash]

This is a mark-and-sweep moving GC, so you'd handle it the same way as the GC handles WeakRef, in between the record and copy steps.

[JeffBezanson]

Oh, I think I tried implementing it that way first --- skipping those fields during the serialize_value step. It seemed ugly to me to add a special case there, but maybe it's no worse than the alternative.

[JeffBezanson]

Ok, this version does seem nicer to me.

[vtjnash]

Better, yes, but it's still corrupting the current runtime by sorting the tn->cache field at the wrong time

[vtjnash]

I don't think these types need to be a special case

[JeffBezanson]

Assertion failed: (jl_svec_len(newa) == sz), function jl_rehash_type_cache, file /usr/home/julia/buildbot/worker/package_freebsd64/build/src/jltypes.c, line 815.

Well, that's unexpected. Gotta love assertions.

[JeffBezanson]

Hmm, I suppose the observed max probe distance is insertion-order-dependent, so rehashing to the same size is not guaranteed to work.

[vtjnash]

yeah, we might want to do some sort of "replacements" htable, then we can put the correctly rehashed value in there? or just put the sentinel nothing in the table, instead of attempting to erase them entirely?

[JeffBezanson]

I'll try that.

[JeffBezanson]

Seems to work. What do you think?

[vtjnash]

Cool, looks like this might save 1-2 MB from the image