Speed of java interpreter in libjava/interpret.cc

[Brad Lucier <lucier at math dot purdue dot edu>]

I noticed that the java bytecode interpreter in javalib/interpret.cc is
compiled with -O2 by default, *and* that it uses gcc's computed goto
extension in an attempt to speed up the interpreter.

Recent changes by Michael Matz to the GCSE algorithm that got rid of
certain code generation errors in the presence of computed goto's
actually slow down the speed of generated code in some instances.  (The
generated code is now *correct*, however.)  I compiled interpret.cc
both with plain -O2 and with -O2 -fno-gcse on
alphaev6-unknown-linux-gnu; on comparing the .s files, I found no
substantive differences in the generated code.  (This may not be what
people expect; the address of insn_target is reloaded for each bytecode
in the interpreter, for example.) So GCSE doesn't seem to help this
code substantially, but it doesn't seem to pessimize it, either.

There is an extension of LCM (the GCSE method used in gcc) to control
flow graphs with critical edges (e.g., computed goto's).  Perhaps when
(if?) that algorithm is implemented, one will find improvements to the
java interpreter's speed.

Brad Lucier