• Stretto (16/16) Nov 17 2013 What is the crucial reason why the current GC has to stop the
• Paulo Pinto (5/10) Nov 17 2013 Because so far no one created a better one to integrate into D compilers...

"Stretto" <uiy12345 gmail.com> writes:

What is the crucial reason why the current GC has to stop the 
world? It would seem to me that only memory defragmentation would 
require such a step? If so, then could we not turn off 
defragmentation and allow the GC to run in the background to 
clean up unused memory and maybe periodically manually defragment?

Also, With the new std.allocator it would be nice if either

1) crucial parts of phobos were rewritten to use allocators such 
as file and console io. This would allow one to have basic 
routines without requiring the GC or reimplementation.

2) Use a dual heap with two GC's where phobo's routines live. 
When one heap is being collected by the GC the other one becomes 
active effectively allowing a concurrent GC. By having only 
phobos and internal routines work on these heaps they should be 
allowed to be much smaller(hence quicker GC collection and 
prevent stopping the main thread).

These options would allow more predictable real time behavior.

Paulo Pinto <pjmlp progtools.org> writes:

Am 17.11.2013 17:21, schrieb Stretto:
 What is the crucial reason why the current GC has to stop the world? It
 would seem to me that only memory defragmentation would require such a
 step? If so, then could we not turn off defragmentation and allow the GC
 to run in the background to clean up unused memory and maybe
 periodically manually defragment?

Because so far no one created a better one to integrate into D compilers.

It is an implementation issue that will be eventually fixed.

--
Paulo