> Hi David,
>

<snip>

>
> I get that and I don't want to debilitate developing packages that run I
> both variants.  But in the case of memory management the two systems are
> very different.  Spur can't support object age.  Spur provides pinning.
> The two have very different garbage collectors and compactors.  In
> developing policy code to control the gcs it will inevitably require a
> different approach to effectively control either.  So in the realm of GC
> (including this, which is reporting GC stats) I think it makes sense to
> let them diverge.  AFAIA OSProcess doesn't depend on GC control facilities
> so it shouldn't affect you.

Way off topic, but speaking of OSProcess and Spur, I'm very much looking
forward to trying RemoteTask on 64 bit Spur. I am expecting it to be very
memory efficient even for extremely large object memories, due to the much
improved memory layout that should localize changes to the object memory
and reduce GC impact.

Dave



>
> Where it may effect you is that pinning could conceivably allow you to
> lift up parameter processing to create the pointer arrays from that rather
> complex primitive into the image, given an addressOf: prim.  Just as I
> hope the threaded FFI will make it possible to interact with output pipes
> much more reliably and efficiently.
>
>>
>> Dave
>
> _,,,^..^,,,_ (phone)
> best, Eliot
>