[gclist] gc concerns

[Nigel Bree]

Charles Fiterman wrote:
> So if gcIdle() halts a collection the work is simply thrown away. Our
> results with pseudo incremental collection make us think incremental
> collection isn't really important.

Thing is, the server in question is probably for a massively multiplayer
online RPG. Essentially it's a long-running world simulation, which will be
cranked fairly rapidly. How rapidly, and how much of their server memory
load is static geometry data (and whether that geometry is represented in
detail in their object system or their high-level simulation code treats it
as opaque primitives) etc. depends on their design choices.

MMORPG and shooter clients typically run limited versions of the simulation
on their side to deal with network latency, so covering GC latency via that
is possible. The main effect of the GC latency would be to make the server's
simulation clock run a little slow, then a little fast to catch up. The
hassle with the client-side prediction is how the client integrates server
data; in game systems like EQ, the visual effect is that players can appear
to take two (predicted) steps forward, then teleport back a step when the
official server update arrives.

All in all, I'd say the Great Circle approach to incremental collection
wouldn't fit this case, unless the allocation rate is actually low enough
that the collector pause is minimal. What the allocation rate is will depend
on things like how the world simulation is divided up between servers, and
whether that is done statically or is dynamically tuned.

Anyhow, one of the original points not addressed is pretty interesting...

Mike Roberts wrote:
> i've noticed that collection isn't a partial commitment. since we are
> using third party toolkits that haven't been written for use with garbage
> collection, would this present a compatibility problem?

Actually, intermingling isn't too bad; GC tends to transitively infect many
parts of a system if you don't have finalizers to deal with pointers to
non-GC objects in your GC objects, but I've found that to be not a problem
in practice (even though, like Charles, I'm wary of general-purpose
finalizers and don't use them in my project's GC). I do, however, have a few
special-case finalised classes which exist solely to release handles to
third-party objects like COM interface pointers where no resurrection is
possible.

The real practical concern is whether pointers to your objects get exported
to third-party code, and if live references in the third-party code need to
be scanned. It also depends on how the third-party library is linked to your
code; on Win32, a third-party DLL can have its own allocator that you have
no control over whatsoever, for instance. A statically linked third-party
library that just calls the same malloc () as your code is no burden at all.

Having to scan third-party heaps at the page level (as is the worst case on
Win32) is really unattractive; if you can restrict your conservative search
to just your application heap, and only the allocated parts of that heap
(page-level scanning of third-party data can't tell what is free and scans
everything) it will be *much* faster.