Possibility of non stop-the-world GC in the future?

deadalnix deadalnix at gmail.com
Mon Feb 18 06:38:15 PST 2013


On Monday, 18 February 2013 at 12:54:24 UTC, Benjamin Thaut wrote:
> The main problem is that programming with a GC encourages 
> programming with memory leaks. As the gc will take care of any 
> leaked memory and you don't get any feedback about how much 
> memory you actually allocate.

You can apply the same reasoning to any language feature.

Bound checking encourage lazy buffer overflow checking. OOP and 
functional encourage indirect branching. And I can go on and on.

Everything that help a programmer is generally good, as long as 
getting performances back is allowed with extra work (what 
GC.free allows you to do). In other terms, if you free what you 
allocate you get back to manual memory management (well, expect 
some runtime weirdness).

> Also even if you do manual pooling and use a GC you still pay a 
> big performance impact because the GC will scan the pooled 
> memory without actually freeing anything. But scanning takes 
> time too. And those interrupts by the GC will be long enough to 
> interrupt regular gameplay.
> D would at least need a incremental Mark & Sweep to be usable 
> in games. But in my opinion a GC is not needed at all when 
> developing games, it makes a lot of sense for other fields 
> though.

You'll find that in term of memory management, no magic solution 
exists. Sometime GC is faster, sometime relying on manual memory 
management is the best. Most of a the time an hybrid approach 
between several techniques best results.


More information about the Digitalmars-d mailing list