harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Griswold <bgrisw...@terracottatech.com>
Subject Re: Thoughts on VM
Date Thu, 12 May 2005 05:12:41 GMT
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" <dmitrysj@earthlink.net> 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" <kevin.jackson@it.fts-vn.com> 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
>>> 
>>>    
>>> 
>> 
>>  
>> 
> 

-- 




Mime
View raw message