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

[Eliot Miranda]

Hi Andres,

On Oct 19, 2014, at 7:54 PM, Andres Valloud <avalloud at smalltalk.comcastbiz.net> wrote:

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

Yes that'll work nicely.  At one stage the Spur implementation has all the objects in the segment and they have their mark bits set, plus a copy of these objects in a word array that becomes the segment.  Next step is to enumerate references in the copy, mapping oops to either segment-relative or indexes into the out pointers, the external references.  At that point I can set the second mark bit on all objects strongly referenced from within the segment.  Then a second pass of weak objs can nil refs to internal objs without the second mark but set.


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

IMO the only sane thing is to treat then as strong objects.  If something gets finalized twice so be it; there's no way to complete finalization while the segment is being created anyway, so even if segment creation queues ephemerons  fir finalization they'll still be in the segment.  There are lots of potential issues here which the segment creation primitive can't deal with ( stale file handles, dangling C pointers ), so expecting it to work miracles with ephemeral references is a waste of effort.  KISS.  No queuing of ephemerons for finalization; just mark as if strong.


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

Eliot (phone)