[gclist] gc concerns

[Mike Roberts]

Nigel Bree wrote:
> 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.

yes, this server is exactly as described. wire frame primitives should be
all that we need to store in world-server memory.

Nigel Bree wrote:
> 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.

i'm informed that existing implementations (like eq and uo) divide up their
servers by geographic regions. i'm trying to avoid this because this
solution does not scale. for example, in asheron's call, if too many people
congregate in one spot, they are teleported outside the area (to another
server) because the server handling that geographic region cannot handle the
increased number of connections.

the design that we are considering involves dividing the map into smaller
regions that can be instantiated on any server node, and only the regions
occupied with avatars are instantiated at any one time. as a result, the
rate of allocation for each map region is inversely proportional to
frequency of player occupation. hopefully, this means a low overall rate of
allocation. of course, this probably makes no sense if i completely
misunderstood what "rate of allocation" means. :)

by dynamic tuning do you mean load balancing the server traffic? we're
hoping to do that, which would increase the rate of allocation only if we
decide to dynamically offload traffic from one server to another as opposed
to balancing traffic upon object instantiation only.

Nigel Bree wrote:
> 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.

this is good to know. i had meant to ask about dlls.

my biggest worry is the fact that we would also like to use the ACE toolkit
<http://www.cs.wustl.edu/~schmidt/ACE.html>. part of the toolkit's offerings
include things such as memory pools. i've never worked with memory pools or
related techniques before, so am i correct in assuming this won't be a
problem as long as we use lib archives instead of dlls?