Bob Griswold wrote:
I just want to put in my 2 cents here.The performance of the VM doesn't actually matter that much in a long-running application. It might make the code generation cycle faster (leading to faster start-up time, but not if it takes time to optimize the VM) or GC's to happen faster, but the VM code takes up typically less than 10% (usually far less than 10%) of the overall application performance time, so even if you double the performance of the VM, you will only get a small improvement in overall application performance.
Bob
From my experience GC efficiency is the most critical component for large long-running server applications running on multi-CPU machines.
For the last few years, I've been working with a company that writes and supports such an application. It runs on 4-way and 8-way Solaris boxes mostly and services hundreds of concurrent users. The main performance problems we've seen can all be traced to garbage collection locking down the whole VM, all 8 CPUs, to do its thing. In fact, the more CPUs, the faster you end up generating garbage and filling up the heap, and therefore the more frequent are the GC pauses. This basically kills the scalability of the VM and an application running on it.
Granted, this was with the 1.3 and 1.4 versions of Sun's VM. I don't have direct experience with 1.5 to know if the situation has been improved. I heard that that may be the case. But I was just trying to point out that GC performance can be very critical of the overall performance of an application.
This exact problem is documented at the following URL: http://java.sun.com/docs/hotspot/gc/. Notice how the % of time spent in GC grows with the number of CPUs to the point where it becomes a dominant factor in the overall performance.
Regards -dmitry
On 5/11/05 6:49 PM, "Kev Jackson" <[EMAIL PROTECTED]> wrote:
First post so be kind!
I was thinking about this last night after reading some posts. Current VM's use JIT or dynamic profiling/performance optimisation techniques to improve the code running on them, but this only applies to application code. Would it be possible to write the VM in such a way as the VM itself is able to be optimised at runtime?
This would essentially mean that each application would be running on it's own custom VM. Ok it's a non-trivial proposition, but with enough initial thought I'm pretty sure something like this could be written. Whether or not it's a good idea - well that remains to be seen.
To accomplish this I would think that the majority of the VM would have to be written in a highly dynamic language (lisp-like) to allow for run-time modification, with a small core algorithm in C to handle the optimisation of the VM. I would also suggest using lisp to write the basic tools, not because I know lisp inside out, but because it's a language that fits the problem domain of writing other language interpreters/compilers extremely well.
Just some thoughts, is this possible/useful?
Kev
