June 13, 2005
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];

June 13, 2005
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