"pause" garbage collection in parallel code

[Stephan Schiffels via Digitalmars-d]

On Monday, 15 December 2014 at 11:54:44 UTC, Daniel Murphy wrote:
> "Stephan Schiffels"  wrote in message 
> news:wjeozpnitvhtxrkhulaz at forum.dlang.org...
>
>> I see several ways how to improve my code:
>> 1.) Is there a way to tell the GC the maximum heap size 
>> allowed before it initiates a collection cycle? Cranking that 
>> up would cause fewer collection cycles and hence spend more 
>> time in my multithreaded code?
>
> Yes, sort of.  You can use 
> http://dlang.org/phobos/core_memory.html#.GC.reserve to have 
> the GC grab a big chunk of memory, and collections won't run 
> until that is exhausted.  As it is only allocating virtual 
> memory, it should be more or less equivalent to setting the max 
> heap size.
>
>> 2.) Is there a way to "pause" the GC collection for the 
>> parallel part of my program, deliberately accepting higher 
>> memory usage?
>
> Yes, with GC.enable and GC.diable
>
>> 3.) Most of the memory is used in one huge array, perhaps I 
>> should simply use malloc and free for that particular array to 
>> avoid the GC from running so often.
>
> Yes, this may work if it's a reasonable design for your 
> application.  Other options like re-using one GC buffer per 
> thread might work too.
>
>> I am a bit surprised that there is no command line option for 
>> dmd to control GC maximum heap size. Who determines how often 
>> the GC is run? For example, in Haskell I can simply set the 
>> maximum heap size to 10Mb in GHC using -A10m, which I used in 
>> the past to help exactly the same problem and dramatically 
>> reduce the frequency of GC collection cycles.
>
> Being able to configure the GC at run-time is something that's 
> currently being worked on.  I assume this will be possible 
> rather soon, probably in the next release.

Excellent, thanks everyone, problem solved. I use GC.disable and 
GC.enable for now, works like a charm. I new about these 
functions, but I thought they prevent GC-allocation, not just 
collection.

Using ThreadLocal storage with std.parallelism is also 
interesting, I won't need it now, as the memory is still within 
manageable bounds, but certainly an option to reduce the memory 
footprint... nice!
And yes, I saw GC.reserve just after I wrote this thread, it 
seems to do what I wanted.

Stephan