www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GC

reply k_mar seznam.cz writes:
I'd like to ask a few questions concerning the current implementation of GC.
first, it seems that the gc is quite slow, pausing all currently running
threads. but what if a background thread waiting for some important events to
occur gets interrupted by the gc while a new event is available? this could
really be a problem. pausing for a very little amount of time should be
acceptable, though (very little: let's say 128MB used memory, up to 50ms on a
high-end CPU - 4G?).

Q1: will there be a revision of the current GC implementation in some of the
future releases? I know it's part of the Phobos runtime library so it isn't
actually related to the language itself, but having a good GC is essential to
achieve good performance with D

Q2: because of C/C++ legacy pointer support, the collector has to scan all
allocated blocks for references, including statics etc. this can lead to bogus
pointers to gc memory blocks. although the probability of this to happen is very
low, it CAN happen. but this concludes that one should really avoid to allocate
big blocks using the GC. is there a chance that we could benefit from gc while
working with large dynamic arrays? or do we simply have to pray that there's no
floating point constant being a bogus pointer? ... I'm desperate:( consider the
following code (i386, 32-bit):

uint gc_big_killer[1048576];
Jun 13 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 13 Jun 2005 10:31:39 +0000 (UTC), <k_mar seznam.cz> wrote:


 I'd like to ask a few questions concerning the current implementation of  
 GC.
 first, it seems that the gc is quite slow, pausing all currently running
 threads. but what if a background thread waiting for some important  
 events to
 occur gets interrupted by the gc while a new event is available? this  
 could
 really be a problem. pausing for a very little amount of time should be
 acceptable, though (very little: let's say 128MB used memory, up to 50ms  
 on a
 high-end CPU - 4G?).

 Q1: will there be a revision of the current GC implementation in some of  
 the
 future releases? I know it's part of the Phobos runtime library so it  
 isn't
 actually related to the language itself, but having a good GC is  
 essential to
 achieve good performance with D


Yes, IIRC, future plans include other GC implementations (In fact phobos  
may end up with several options allowing you to select a GC type per  
application - perhaps). The current GC is simple, which is all that is  
required at present (at least, that is the rationale behind not spending  
the time improving it, right now).


 Q2: because of C/C++ legacy pointer support, the collector has to scan  
 all
 allocated blocks for references, including statics etc. this can lead to  
 bogus
 pointers to gc memory blocks. although the probability of this to happen  
 is very
 low, it CAN happen. but this concludes that one should really avoid to  
 allocate
 big blocks using the GC. is there a chance that we could benefit from gc  
 while
 working with large dynamic arrays? or do we simply have to pray that  
 there's no
 floating point constant being a bogus pointer? ... I'm  
 desperate:( consider the
 following code (i386, 32-bit):

 uint gc_big_killer[1048576];


See:
http://www.digitalmars.com/d/memory.html#uninitializedarrays

Arrays are all initialised, so, no bogus references/pointers are possible.  
However, this is not fast, so VoidInitialisers can be used to prevent it.  
The idea being that you'll soon be filling the memory with valid data,  
ideally without allocating more memory (triggering a GC sweep).

Regan
Jun 13 2005