[vworld-tech] Modern MUD server design

[ceo]

Brian Hook wrote:
> 
> If you're using a compile/link language like C/C++, then having to 
> recompile and relink everything just because you've changed an orc's 
> pathfinding algorithm can suck since you have to bring down the world 
> (you could, in theory, use shared libraries, but that presents its own 
> set of problems).
> 

Since you mentioned java on the client-side...have you used java for 
server-side dev before? One of the powerful features is it's flexibility 
with classes at runtime...

For instance, we have a system which "upgrades" a compiled classfile 
(and hence all current objects created from that classfile) on a live 
system. A simple version of this is so easy to code in java it can be 
done in only about 100 LOC. Unlike some scripting languages, this 
reloading is done without much overhead; the only performance penalty 
you're likely to notice is that Hotspot may have to start it's "compile 
to native code, test, evaluate" cycle all over again for that class; 
whilst this won't *necessarily* reduce performance, it may take up to a 
few minutes before that class has been fully optimized as native 
low-level code.

However, because the reloading is done without much overhead, the 
objects themselves tend to be expensive to convert. Whereas a scripting 
language might have "slower" classes, the accompanying soft objects are 
much easier to upgrade when the class changes. E.g. if your objects are 
actually implemented as hashtables, and are little more than syntactic 
sugar, then "upgrading" them can be much much faster than in Java, where 
entire new Object's need to be created in memory, and all data copied 
from the old ones.

(nb: I don't work on JVM-related stuff, and my knowledge of HS and when 
and how it does it's feedback-directed optimization is sparse; however, 
we don't tend to see noticeable performance degradation when reloading 
classes)

Adam