Efficient dynamic method dispatch on the JVM is hard. Since classes can
be loaded at any time, even a call site has been executed, you need to
use reflection. But explicitly considering the signatures of all
relevant methods every time is slow. And reflection is slow, too slow
to be used for every single method call.
So there are various tricks: call site caching lets you skip the method
determination logic most of the time. And once you've determined a
method, you could generate a little bytecode at runtime to do a direct
method call, avoiding reflection.
But that bytecode may have to change if new classes are loaded or new
types are used to dispatch, so we'd like it to be garbage collected.
Since the class loader maintains a hard reference to the class, we need
to wrap each one in its own classloader. All of this lives in the
PermGen, so in the end we can't have many of them.
So we end up with a somewhat complicated strategy. JRuby starts by
interpreting the AST; after a while it will compile it to JVM bytecode,
which uses reflection; Ruby core methods have wrappers that call them
directly (i.e. without reflection) and that don't need 1 classloader per
method; but not for Java's standard library, since that would be too
many classes.
So this is a large engineering project that all dynamic languages on the
JVM have to wrestle with. Is there scope here to share work? A common
architecture, perhaps a lot like invokedynamic, e.g. a call site cache
with a guard? LRU logic for evicting old JITted call sites?
Best,
Martin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
