[Mono-devel-list] Limiting Memory Allocation

[Richard Matthias]

I hate popping up on mailing lists without any introductions, but anyway...

I can't help feeling that you're going about this in the most complex
way possible. Given that you are generating all the code from a source
script at runtime, why don't you just inject code to monitor memory
usage inline? Unless you are revising LSL (I'm a secondlife user) all
data operations are value based, so it's pretty easy to see where
memory is freed.

There would be an intermediate time between the script's memory
counter being decremented and the GC actually recovering that memory
which would potentially allow scripts to lag the server by creating
tons of garbage, but you could limit that by accounting for memory
allocation events in your scheduling.

btw. I'm curious as to how you are dealing with the issue of
assemblies (dynamically generated or otherwise) not being unloadable?
.NET is pretty badly designed for handline dynamic code in the way
you'd want to for a game server. The only way you can unload code is
to load that code in a seperate AppDomain and unload the AppDomain
when you're done with it. Of course you can't load every script into
it's own AppDomain because each has a large allocation overhead. There
is also a significant marshalling overhead when calling across
AppDomains. The alternative is to generate code in a single AppDomain
and put up with the fact that you're going to leak memory as users
load new scripts and recompile existing ones. As you need some way to
serialize script state anyway, I guess you could serialize all the
scripts periodically and unload the AppDomain and start again.