[Vm-dev] Re: [squeak-dev] Image Segment semantics and weakness
avalloud at smalltalk.comcastbiz.net
Mon Oct 20 02:54:04 UTC 2014
How about this?
Step 1. Mark segment roots with mark bit B.
Step 2. Trace from system roots marking with mark bit A.
Step 3. Trace from segment roots marking with mark bit B.
Step 4. Hey, all those objects that could not be referenced from either
the system roots or the segment roots are garbage! And between mark
bits A and B, there is now a complete trace of the system. Finish off
the GC, and unset any mark bits A only. This should fix weak arrays.
Step 5. Trace from the segment roots and write anything marked with
mark bit B to the segment, unsetting mark bits B along the way.
The key is to use 2 mark bits, where setting either means "the object is
marked" as far as the GC is concerned. What, no available header bits?
Surely it's possible to pull off a Peter Deutsch, "let's squirrel away
information in bits used for something else as long as nobody notices"
kind of trick :).
Ephemerons are still problematic. Should they be finalized both in the
host image, as well as in other images that load the image segment? I'd
consider letting ephemerons queued for finalization during step 4 become
regular strong objects in the image segment, such that loading them into
a new image does not trigger random finalization. Steps 4 and 5 produce
that for free (because ephemerons in the finalization queue become
regular strong objects).
On 10/19/14 19:05 , Eliot Miranda wrote:
> Oh thats a very good point. I new it was wise to ask :-) I'll sleep on
> this but at the moment I'm close to being convinced that there either
> needs to be the equivalent of a GC immediately on loading, or the
> equivalent of a GC on creating the segment, so as not to include
> category three objects in the segment. Damn, I suspect that's tricky to
> implement efficiently ;-)
More information about the Vm-dev