>  As I already mentioned here, we need a possibility to load a modules in
> runtime. Bytecode is fast, but not enough for a killer web architecture.
> So, we need a JIT, or, which will be much better, an object format
> including intermediate lambda-trees to compile it and link at runtime.
> Even a PIC code for native will not be enough, 'cause of a great overhead.

I fail to see the logic in this argument.

First, position-independent native code is indeed a bit slower than
statically-linked code on some platforms, but surely JIT-produced code
is much worse.  If you don't believe me, compare performance between
gcc -fpic -O and any Java implementation :-)

In other terms: those who can, compile ahead of time; those who can't,
compile just in time.  A prime example of those who can't is Java:
they screwed the definition of their language so well that it makes
traditional compilation impossible; hence their propaganda about JITs.
We (Caml) can...

Second, you (and others) seem to take for granted that a "servlet
container" must load servlets dynamically into its own memory image.
That's the Java way, but again that's not the only way.  Using
separate processes for the HTTP server/servlet container and for the
servlets (but not starting a new servlet process on each request like
CGI does) might very well work better: I'll bet the performance hit
would be insignificant, and you get a clean, well-specified
communication protocol between server and servlets.

That's just one idea, but my general point is that the Java (or .NET)
approach is not necessarily the right approach.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr