General Problems for GC'ed Applications?

[BCS]

Karen Lanrap wrote:
> Walter Bright wrote:
> 
> 
>>that would be a terrible design if it did.
> 
> 
> Then have a look what the code below compiled (dmd 0.163; win) is 
> doing under XPSP2.
> 
[...]
> 3) veriify in task manager, that allocated memory is about 400M
> 4) minimize shell
> 5) observe in task manager, that allocated memory reduces to 100M
> 
[...]

I don't see how this demonstrates that a GC'd app will cause more 
thrashing than a non-GC'd app. First of all, is that 400/100M quote the 
actual Physical memory usage, or the virtual memory usage?

Even if the program IS using more (virtual) RAM it won't inherently 
thrash the system. Thrashing is caused by /access/ to more memory than 
is available, not by having more memory /allocated/ than is available.

Having lots of "lost" memory around is quite unlikely to cause thrashing 
because, In all likelihood, the extra ram is inaccessible due to lack of 
pointers to it. As such It won't get accessed and will never get swapped 
back in. An exception to this is if the GC maintains some sort of 
tagging of memory block that is located at the block it's self. Then 
some kinds of GC actions will cause the "lost" blocks to be read, and 
thus swapped in (and probably deallocated a short time later).

The accessible memory on the other hand, _will_ get scanned by the GC on 
a full collect. This could cause some thrashing. However, unless the GC 
only frees up enough memory for each allocation (this would not only be 
a bad design, but a stupid one as well) most allocations won't result in 
any collection at all.

As to swapping, the same logic applys to the OS's swapping algorithm. 
Typically OS's try to keep a pool of free memory available by swapping 
stuff out when it has the time. Most of the time, allocations and page 
faults don't require anything to be swapped out.