Re: Proposal: runtime-modifying Kernel methods should be keywords

On 13/07/07, Charles Oliver Nutter <[e-mail]> wrote:
> The languages you list either use keywords or expose runtime structures
> (like variable scopes, call frames, and bindings) as first-class
> entities in the system. Ruby does neither.
>
> And hotspot evolved out of self and strongtalk, so I'm not sure I
> understand that logic.

Hotspot supports dynamic deoptimization. This enables optimistic
optimizations. For instance, the hotspot compiler does method
inlining, but dynamic class loading can at any time invalidate that
optimization (unless you'd only inline final methods, which is useless
in practice.) The hotspot compiler detects this invalidation, and
undoes the inlining. It can even undo the inlining for a running
method. Unrelated to this, I've read papers on a technique that does
optimizations optimistically, and inserts code to check whether the
optimization was valid. If it wasn't, execution falls back on the
original code. If the optimization is valid most of the time, this
results in an overall speedup.

These techniques can also be applied to your problem. For instance,
you need to detect the presence of a call to eval, or to an alias of
eval. At each point in the execution, the Ruby runtime knows the
aliases of eval and can decide what optimizations are valid. If an
alias is added or removed, the affected methods can be checked and
optimized/deoptimized as appropriate. My impression is that currently
you only do static, intraprocedural optimization (correct me if I'm
wrong). In practice, dynamic optimization techniques are essential. Or
at least this is what I remember from a talk on the hotspot compiler
by some Sun guy whose name I can't remember. What I do remember is
that method inlining is the most important optimization of all, and
not only because it removes method call overhead, but also because it
enables more intraprocedural analyses. In Ruby, I'd expect this to be
even more important as inlining methods that take a block allows to
remove the overhead associated with that block. But because in Ruby,
methods can be added/removed/redefined at runtime, any inlining can
become invalid. On top of that, eval pretty much rules out even the
best predictions about what methods can be affected.

So, if you really want to get some speed into Ruby, you'll have to use
dynamic compilation techniques, and then you don't need the changes
you are asking for. These changes will make your job easier, but
without these changes, optimization is not impossible. Hard, agreed,
but not impossible. Language runtime designer is not an easy job.
These days, it's probably one of the hardest jobs, but also one of the
most interesting. What would be really interesting is if you could
compile Ruby code to Java code in such a way that Java's JIT compiler
can do the dynamic optimizations for you.

As a side note, in Matz' Ruby, a C extension can easily override eval
without resorting to any trickery (it uses the fact that Matz' Ruby
does not create a new scope for methods implemented in C.) I'm not
100% sure that this is full proof, but it works well enough to wreak
havoc on optimizations that assume that implementing one's own eval is
impossible.

Finally, in my opinion, the reason why eval and all are methods is
because they *can* be. This is the beauty of Ruby, and why it is so
fit for creating DSLs, namely because it can make methods look like
keywords even though they are not. That is important, because keywords
can suck greatly if the perfect name for a method or variable happens
to be a keyword.

Peter