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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
