SSA

[Stephen Weeks]

> First, we can't flatten GC_stack into GC_thread.  The reason is that
> SML code and objects only refere to GC_threads, not GC_stacks.  Now,
> when the current thread runs out of stack space, it copies it's stack
> data to a new, larger stack and updates the stack field of the current
> thread.  This ensures that all ML objects refering to the current
> thread "see" the new stack. 

Ah.  Makes sense.  Should go in the runtime section of the hacker
guide.

> My first attempt at combining all the GC_stack and GC_thread data
> works o.k. for single threaded apps, and even for some
> multi-threaded apps, but mutex.sml and thread2.sml both were
> failing.

I am confused what "first attempt" means.  Is this the scheme that
can't work because of the resizing argument above?

> That all worked out o.k., so I took a crack at setting frame layouts for
> handlers and walking the handler stack as part of GC.
...

Having thought about this idea over the weekend before you sent your
mail, and now seeing your mail, makes me think that we don't want to
go this direction.  I see only costs (performance and code space) and
no benefits.  Here are the costs:

1. extra static data for frame layouts
2. GC_foreachPointerInObject hits pointers twice (and hence forward is
   slower) or possibly is made more complicated to avoid doing so
   (although I don't see how) 
3. accessing the exnStack field is slower due to the extra indirection

The only cost of the current approach is that we may have to create
more stubs to associate framelayouts with each cont-handler pair.

The difference as I see it is that the current approach computes the
union of the sets of live slots due to the handler and cont at compile
time, and represents the union as one set, while the new approach
represents both sets and computes the union at runtime.  I don't see
how this could be better.

> mandelbrot has me completely stumped.

I have no idea.

> The failure of vliw under the new compiler is not directly related to the
> changes I made.  
...
> Anyways, I just found this, so I haven't taken a look at what needs to be
> done to fix it.

I'll look into this if you want.  Or, I can let you and I'll move on
to checkHandlers.

If you're going to be looking at limit checks, here are the known
problems on my todo.

1. It moves checks inside of loops.
2. Stack limit checks imply heap limit checks.  These should be
   separated.  This will remove the heap check from fib.sml.