Using mutable array after an unsafeFreezeArray, and GC details

[Brandon Simmons]

On Mon, May 12, 2014 at 4:32 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> On 09/05/2014 19:21, Brandon Simmons wrote:
>>
>> A couple of updates: Edward Yang responded here, confirming the sort
>> of track I was thinking on:
>>
>>
>> http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/
>>
>> And I can report that:
>>    1) cloning a frozen array doesn't provide the benefits of creating a
>> new array and freezing
>>    2) and anyway, I'm seeing some segfaults when cloning, freezing,
>> reading then writing in my library
>>
>> I'd love to learn if there are any other approaches I might take, e.g.
>> maybe with my own CMM primop variants?
>
>
> I'm not sure exactly what your workload looks like, but if you have arrays
> that tend to be unmodified for long periods of time it's sometimes useful to
> keep them frozen but thaw before mutating.

The idea is I'm using two atomic counters to coordinate concurrent
readers and writers along an "infinite array" (a linked list of array
segments that get allocated as needed and garbage collected as we go).
So currently each cell in each array is written to only once, with a
CAS.

>
> How large are your arrays? Perhaps the new small array type (in HEAD but not
> 7.8) would help?

Thanks, maybe so! The arrays can be any size, but probably not smaller
than length 64 (this will be static, at compile-time).

I read through https://ghc.haskell.org/trac/ghc/ticket/5925, and it
seems like the idea is to improve array creation. I'm pretty happy
with the speed of cloning an array (but maybe cloneSmallArray will be
even faster still).

It also looks like stg_casSmallArrayzh (in PrimOps.cmm) omits the card
marking (maybe the idea is if the array is already at ~128 elements or
less, then the card-marking is all just overhead?).

Brandon

>
> Cheers,
> Simon