A possible performance boost? (James Ladd)

[John Rose]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20091001/a85f28fa/attachment.html