Prim.entersRuntime vs Prim.runtimeTransfer

[Matthew Fluet]

> I don't completely understand the reasoning behind why the particular
> subset of Prim.entersRuntime primitives was chosen for
> Prim.runtimeTransfer.  

Well, to get the once analysis right, we needed to introduce a runtime
transfer for Thread_copyCurrent.  I added the other Prim.t's because they
were the other ones that really had a control flow feel.  I know that some
of the others enter the runtime, but not in a way that affects the control
flow -- array allocation and thread copy could equally well be marked as
ffi's.

> Ignoring deserialize and serialize, which are unused, here are the
> additional prims that are entersRuntime but not runtimeTransfer
> 
> 	Array_array
> 	Array_array0
> 	GC_collect
> 	Thread_copy
> 	Thread_finishHandler
> 
> I'm not sure why we need both of these notions, so I propose to
> combine the two notions into one, called entersRuntime, by eliminating
> the Array prims.  It seems to me that the other three (GC_collect,
> Thread_copy, Thread_finishHandler) are reasonable places to split
> blocks because the runtime is certainly entered at them.  The array
> prims will be handled separately by the new RSSA/limit check stuff,
> which will split blocks so that arrays are at the beginning of a
> block.

I agree that Thread_copy enters the runtime, but only in so far
as it does a form of allocation; I guess that is the issue, doing a
Thread_copy could invoke a GC.  Long term might be to provide
preThread_size primitive to make the allocation more explicit,
as we might do with IntInf's.  GC_collect -- sure, that could go in.

Dropping Array_array and Array_array0 are fine by me; and I've got no
objections to the other Prim.t's being transfers.

Although, Thread_switchTo is a little strange, in that it is explicitly
hand coded to not enter the runtime for a fast transfer.  Just a comment.