shared array?

[Ola Fosheim Grostad via Digitalmars-d-learn]

On Monday, 14 September 2015 at 20:34:03 UTC, Jonathan M Davis 
wrote:
> I'm not sure why it wouldn't be suitable for the typical use 
> case. It's quite performant. It would still not be suitable for 
> many games and environments that can't afford to stop the world 
> for more than a few milliseconds, but it brings the stop the 
> world time down considerably, making the GC more suitable for 
> more environments than it would be now, and I'm not aware of 
> any serious downsides to it on a *nix system.

For me concurrent gc implies interactive applications or 
webservices that are memory constrained/diskless. You cannot 
prevent triggering actions that writes all over memory during 
collection without taking special care, like avoiding RC. A fork 
kan potentially double memory consumption. Gc by itself uses ~2x 
memory, with fork you have to plan for 3-4x.

In the cloud you pay for extra RAM. So configuring the app to a 
fixed sized memory heap that matches the instance RAM capacity is 
useful. With fork you just have to play it safe and halve the 
heap size. So more collections and less utilized RAM per dollar 
with fork.

Only testing will show the effect, but it does not sound 
promising for my use cases.