Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of dmitrysj@earthlink.net
 designates 209.86.89.61 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=simple;
  s=test1; d=earthlink.net;
  h=Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=UKJWgDZh63Sauwz2C5ET6hSL+rvVCqb3DnsOZ77fVZWwmoFaCgBhfcRBCmPbhXPN;
Message-ID: <4282D7C1.9080105@earthlink.net>
Date: Wed, 11 May 2005 22:12:49 -0600
From: Dmitry Serebrennikov <dmitrysj@earthlink.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: Thoughts on VM
References: <BEA8104F.682%bgriswold@terracottatech.com>
In-Reply-To: <BEA8104F.682%bgriswold@terracottatech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>>
>>    
>>
>
>  
>