[Vm-dev] Re: [squeak-dev] Image Segment semantics and weakness

[Andres Valloud]

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).

Andres.

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 ;-)