More radical ideas about gc and reference counting

via Digitalmars-d digitalmars-d at puremagic.com
Mon May 12 09:22:36 PDT 2014


On Monday, 12 May 2014 at 08:45:56 UTC, Walter Bright wrote:
> 2. you can have the non-pausible code running in a thread that 
> is not registered with the gc, so the gc won't pause it. This 
> requires that this thread not allocate gc memory, but it can 
> use gc memory allocated by other threads, as long as those 
> other threads retain a root to it.

This and @nogc is a very promising trend, but you should still be 
able to partion the GC search space.

The key to controlled real time performance is to partition the 
search space, that goes for anything algorithmic; memory 
management inclusive. That applies to any scheme like owned, ARC, 
GC etc. It makes little sense having to trace everything if only 
the physics engine is the one churning memory like crazy.

And fork() is not a solution without extensive structuring of 
allocations. Stuff like physics touch all pages the physics 
objects are onto like 100+ times per second, so you need to group 
allocations to pages based on usage patterns. (No point in 
forking if you get write traps on 50.000 pages the next time the 
physics engine run :-).

> 3. D allows you to create and use any memory management scheme 
> you want. You are simply not locked into GC. For example, I 
> rewrote my Empire game into D and it did not do any allocation 
> at all - no GC, not even malloc. I know that you'll need to do 
> allocation, I'm just pointing out that GC allocations and 
> pauses are hardly inevitable.

This is no doubt the best approach for a MMO client. You have a 
window on the world and cache as much as possible both to memory 
and disk. Basically get as much memory from the OS as you can 
hoard (with headroom set by heuristics) when your application has 
focus and release caches that are outside the window when you 
loose focus to another application. This means you need a 
dedicated runtime for games that can delay GC collection and eat 
into the caches when you are low on computational resources.

You also need to distinguish between memory that is locked to RAM 
and memory that can swap. You should always lock memory for real 
time threads. So if you want to GC this, you need a GC that 
support multiple heaps.

(Some hardware might also distinguish between RAM that is 
accessible by the GPU or that has different characteristics in 
areas such as persistence or performance.)

> 5. you can divide your app into multiple processes that 
> communicate via interprocess communication. One of them pausing 
> will not pause the others. You can even do things like turn off

Why processes and not threads with their own local GC?

> 6. If you call C++ libs, they won't be allocating memory with 
> the D GC. D code can call C++ code. If you run those C++ libs

But what happens if that C++ code does "new 
HeapStuff(D_allocated_memory)" and then calls back to D? You 
cannot presume that C++ coders have the discipline to always 
allocate local memory from the stack, so basically you cannot GC 
collect while there are C++ functions on the stack. In order to 
get there the GC collector needs to understand the malloc heap 
and trace that one too.

Auditing all C++ libraries I want to use is too much work, and 
tracing the malloc heap is too time consuming, so at the end of 
the day you'll get a more robust environment by only scanning 
(tracing) the stacks when there is only D function calls on the 
stack, with a precise collector.

That means you need to partition the search space otherwise the 
collector might not run in time.

Freezing the world is really ugly. Most applications are actually 
soft real time.

Games are part hard real time, part soft real time. The 
difference between games and other applications is that there is 
less headroom so you have to do more work to make the "glitches" 
and "stuttering" occur sufficiently seldom to be perceived as 
acceptable by the end user. But games are not special.




More information about the Digitalmars-d mailing list