[E-Lang] Re: restricted concurrency and optimization (was Re: [E-Lang] E FAQ)

[Mark S. Miller]

At 10:35 PM Thursday 9/27/01, Wesley Felter wrote:
>I don't think you'd need to have two separate GCs, [...] When
>run in reactive mode, the GC would have to scan the stack, 

You're correct.  My "two GCs" remark was based on some old assumptions I 
forgot I was making.

1) It is nice to have a relocating GC, as that also plausibly rearranges 
memory for better working set behavior.  (What's the current scoop with 
this?  The last studies of this I knew were from more than twenty years ago.)
Note that incremental no longer implies relocating.

2) Many desirable compiler optimizations preclude accurate scanning of the 
stack.  Therefore, one should sweep stacks conservatively.  

Putting these two together, the simple thing to do may be to use a 
relocating collector between turns and a stationary collector within a turn. 
Although this is complicated, it still seems simpler than the 
mostly-relocating collector, as an old DEC SRC Scheme-on-C system did in 
order to deal with stack conservatism.  

In any case, I haven't been following this literature for a *long* time, so 
consider the above to be half baked.

In any case, given E's sequential nature, #2 may be much less of an issue, 
since the stack only needs to be accurately sweepable at those times when it 
might be swept, which a compiler could now reason about.  This is yet another 
instance of the original observation.


>but if you do a
>good job of estimating the rate of garbage creation that should be rare.

I buy that.

>Also, if you run the GC at points where the vat would otherwise block
>(because the event queue is empty), then it's possible that GC wouldn't
>"steal" any time from the mutator, making GC essentially "free".

For vats that periodically spend time with nothing else to do, sure.  Vats 
in a server-like role may never be so lucky, but still need high quality GC.


>I am assuming incremental GC, so the vat could do a little GC work every n
>turns to match the rates of garbage creation and collection.

I think I like it.  But count allocations rather than turns.


        Cheers,
        --MarkM