Switch profiling for better switch performance?

[Charles Oliver Nutter]

I'm a little fuzzy on the status/level of optimization HotSpot 
performance based on switch profiling. John Rose's wiki page on HotSpot 
optimizations claims that switches are profiled, but that the 
information isn't used very well. And on JRuby and JOni projects, we 
have seen that large switches have progressively worse performance. John 
mentioned partial work that had been done on optimized jump-tables for 
switch jitting, but I don't know where that went.

I ask because as more languages come online on JVM, we're going to run 
into more cases where a bytecode VM *on top of* the JVM is the right way 
to go. For example. JRuby will want to support the two Ruby bytecode 
implementations in Ruby 1.9 and Rubinius. Jython will want to support 
Python's .pyc bytecode. JOni is already a very fast and fully-functional 
bytecode-based regexp engine.

Using a bytecode machine on JVM could also provide an easier path to 
fast startup and cheap code execution for languages that support eval or 
that are more fluid like Ruby. Currently, in order to save on startup 
costs, JRuby starts out all code intepreted (AST-walking), eventually 
JITing to Java bytecode which is then presumably picked up by HotSpot. 
But we could probably get a performance boost if we could implement a 
fast, stackless bytecode engine rather than an AST walker. At the 
moment, however, we worry about switch performance.

I know resources are a problem, but is there any thought going towards 
improving switch performance? I know at least one JRuby team member that 
could provide some pretty unpleasant benchmark results that show the 
pain we're facing.

- Charlie