[Mono-devel-list] Limiting Memory Allocation
Richard Matthias
richardmatthias at gmail.com
Wed May 4 20:30:02 EDT 2005
I'd suggest for the sake of your productivity you go with the former.
That will give you the opportunity to implement the security you need
at the compiler level and also inject code at the compiler level to
manage memory and do any other accounting you need.
Even with CAS on Microsoft's .NET, the system isn't really geared to
running the way you need to on a game server. In contrast with the
Java JVM, the philosphy of .NET isn't one of a virtual machine within
the machine. Instead .NET is meant to be a layer over OS functionality
that just makes stuff easier for developers. The practical upshot of
this is for example is if you need to schedule lots of code to run
concurrently you have to use OS threads. That's OK for a web server
that might have 10 or maybe 20 ASP.NET apps running on it, but if you
gave every script on a SecondLife server a seperate thread the machine
would grind to a halt. Likewise .NET doesn't have a mechanism that's
explicity designed for handling memory allocation. You can do some
stuff using the profiler API as you've seen but it's clearly not
intended for that use. Also, if you need to inject code into a random
.NET assembly, you can do that using the profiler API (with a lot of
additional code of course!), but it's easier and more robust to create
a modified assembly on disk ahead of time instead.
A lot of stuff in .NET 1.x seems geared to support the ASP.NET server
which figures as they are probably the most advanced 'customer' of the
CLR in that version. A lot of stuff is added in .NET2 to support the
embedding of the .NET runtime in SQL Server. Still doesn't support
code unloading although it does have that Dynamic method thing. Unless
you're a big Microsoft product team though it's probably quite hard to
get features added to the .NET CLR :)
More information about the Mono-devel-list
mailing list