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