On Sep 30, 2009, at 11:41 PM, James Ladd wrote:
Does anyone see a reason this could not be tried, or has it been tried and what were the results?
Many ideas like this have been tried over the last 12 years. There are engineers working full-time in and with hardware vendors on such things. There is no shortage of clever ideas, only of people to try them out and actually demonstrate that they work on real hardware with all the actual strange effects of modern caches and pipelines and branch predictors. The way to evaluate a performance idea is to work it out in detail and test it on real workloads (not micro-benchmarks).
Until then, I think it's going to work out like Richard Feynman observed, "You cannot prove a vague theory wrong."
I would encourage you to build the JVM, run it on something plausible, and use a performance analysis tool to find out where the time actually goes. It won't be anywhere near the interpreter, I predict. That's historically been the result of interpreter hacking. You might find a bottleneck in compiled code that's worth optimizing. What I'm saying is that performance is determined by compiled code.
There's a similar problem which may interest you, more amenable to static analysis, which is to reduce the memory footprint of the JVM. For a tiny-footprint JVM, the interpreter performance might be of some importance, but the optimization problem is speed + space, rather than speed only.
Good luck, -- John
_______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
