RE: GC "survey"

[Nick Trout <Nick.Trout@...>]

> But again, why do you want to free up the space taken by 
> "NPC dialogue"? Something between the loading of different 
> levels? I usually just put all of them in one place, and 
> they will be freed by lua_close() anyway. 


The whole issue to do with garbage collection is about optimisation and
diluting the workload I think. We could get significant speed increases by
not sweeping data which we know doesn't need collecting. What if the Lua
objects lived in modules and you could sweep inside the modules on demand.
I'm not sure if the new namespace implementation would handle this. The
issue with garbage collection is checking referencing and only freeing
unreferenced objects. References would not be able to look into other
modules, i.e. an interface would have to be enforced and members kept
private, they would have to go through an interface. Perhaps the "index" tag
could be used to access object in namespaces. Perhaps the overhead of having
weak references to data in other modules would be less than the overhead of
global garbage collection. You would have control over modularity in your
project and if GC was an issue you could make the modules more granular and
schedule the GC on them individual at will. If you decided a module was no
longer valid you could remove it and force a global/module sweep. Any
attempts to reference objects in removed module would result in the usual
"module/table does not exist" or "module says object doesnt exist" message.
C objects could be wrapped and managed like this also.

I think this suggestion assumes that all of the objects are created are kept
in a module table which is easy to traverse for sweeping. Perhaps new Lua
states could be created to hold modular data and a fast interface added, or
the way objects are stored modified, to optimise this way of treating data.

Apologies if this suggestion is ill informed. I'm finding this debate very
interesting and it will be of great relevance to me in a short time!

Regards,
Nick