The types of bytecode you choose to generate will have a major impact on
how the VM performs. I ask because if you are doing mostly math then the
gains will probably be directly proportional to the number of byte codes,
unless
your platform has difficulties with multiply/divide. If you are using
objects and
frequently abandoning them, then new and GC's will dominate. If you are
writing highly factored code, then method invocations could dominate.

You can calibrate any given VM with looping code and the
internal timers. The things to remember are to disable any JIT/AOT, usually
with a  command line parameter like -Xint (means interpreter only) and you
can generate the class files manually using one of several free bytecode
assemblers like Jasmin. You should by preference use the internal java
timers,
but remember to "warm" the VM by running everything at least once to make
sure that all relevant classes are loaded and method invocations have been
resolved so you're not measuring start-up time. i.e. don't just have other
calls
to the same routines, but run the exact same bytecodes as some VMs
resolve each bytecode and some VMs resolve a central entry like the
constant pool, so unless you know the internal details of the VM, be
careful.

You probably need calibrate only a small fraction of the byte codes as few
are likely to be used and many are rare in the wild. e.g. all the iconst_x
bytecodes are probably identical, all the if_x are probably identical, all
the
if_icmpx are probably equal, all logic and/or/xor are probably identical,
dup_x instructions are extremely rare in the wild and typically not worth
profiling, aload_x/astore_x should be calibrated separately from iload_x/
istore_x as some GC implementations use the aload/astore instructions to
implement read and/or write blocks so they may differ from iload/istore
which just move integers between local variables and the stack.

If you tell us the type of programs you are writing, I could be more
helpful.

You can also try downloading the Sable research VM from McGill Univ.
and look at the implementation of the individual byte codes.

Mark...

It does not really matter if they do out of order execution.  It is
repeatable. the count you get is both an accurate count of ticks of
time, and cpu work.  Some instructions take differing numbers of
cycles depending on the operands.  

The problem is though there is so much other stuff going on in the
background in your OS that can throw of your measures, since they show
up in the counts too.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.