On Jan 29, 2016, at 12:39 PM, David T. Lewis <lewis at mail.msen.com> wrote:

>> 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.

Then I need to write Mac make files, which is the only thing standing between me and a new release that includes the 63-bit sour Cogit.

>> 
>>> 
>>> Dave
>> 
>> _,,,^..^,,,_ (phone)
>> best, Eliot
> 
> 
>