GC efficiency is very different than the speed at which the JVM runs it's GC code.
On 5/11/05 9:12 PM, "Dmitry Serebrennikov" <[EMAIL PROTECTED]> wrote: > Bob Griswold wrote: > >> 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 >> >> > I just want to put in my 2 cents here. > 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 >>> >>> >>> >> >> >> > --
