Melvin Smith writes: > The downside to our implementation is in the return continuation case. > The common case is to create the continuation that you plan to > return with, and you already know there will be no need for > copy-on-write in most cases because typically the execution > path will return using that continuation, and that will then become > the "main" execution context. The original interpreter context and > all its associated stacks that existed at the time of the snapshot > will usually immediately be readonly orphans as soon as you activate the > return continuation (unless you saved the initial main context first). > It'd be more optimal to skip marking COW altogether in certain cases.
That's what the RetContinuation class does if I'm not mistaken. But RetContinuation is a bit presumptuous about what is going to be done above it. It must be guaranteed that nobody will try to use the RetContinuation as a regular continuation without first promoting it (I can see a way to make such promotion possible, described below). There are three ways I see to reduce this overhead. The first is to make the register stacks a linked list of single frames -- no chunks. We could make object pools for each of the register frame types to keep allocation quick. This would avoid copying altogether in the common case, but it wouldn't get by marking everything COW. Plus, the copying would still happen eventually (I can't think of a way to safely unmark things COW without copying), just not as much. In particular, the asymptotic complexity stays the same. The second is to move the used counter out of the chunk and into the stack structure. This way RetContinuations can be promoted into real Continuations as long as the stack frame associated with the RetContinuation has not yet exited. The last way is to keep a set of 16 flags in each chunk that mark whether a return continuation has been taken at that point, and if you try to pop beyond that point, the stack is marked COW and copied. This is effectively lazily promoting RetContinuations into real continuations. None of these seem optimal at this point, although #2 is definitely something that could be useful. Luke
