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

[Wesley Felter]

On Thu, 27 Sep 2001, Mark S. Miller wrote:

> At 09:40 PM Thursday 9/27/01, Wesley Felter wrote:
> >This reminds me of some other thoughts I had about optimizing E runtimes.
> >GC could be simplified if you know that all the code touching the GC heap
> >is single-threaded. You could also avoid scanning the stack for GC roots
> >by running the GC in between game turns (since there would be no E frames
> >on the stack at that point). You wouldn't need complex thread-suspending
> >logic or GC safe points in every loop.
>
> Yes!  The only precedents I know for GCing only when there are no stack
> frames are Niklaus Wirth's Oberon system (which the world should have paid
> more attention to) and Udanax Gold/Purple
> http://www.udanax.com/gold/index.html http://www.sunless-sea.net/forum .
> Both are event-loop systems.
>
> If you want to do this, the hard question is: What happens if you run out of
> space during a turn?  I believe the least bad answer is to have two garbage
> collectors.  Yuck.  But probably still wirth it. (Sorry)

I don't think you'd need to have two separate GCs, but you'd at least want
a GC that could be invoked reactively (we are out of memory, please create
more) and proactively (there are no game turns runnining right now, so
free up some memory in anticipation that future turns will need it). When
run in reactive mode, the GC would have to scan the stack, but if you do a
good job of estimating the rate of garbage creation that should be rare.
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".

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.

Wesley Felter - wesley@felter.org - http://felter.org/wesley/