You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Kev Jackson <ke...@it.fts-vn.com> on 2005/05/12 03:49:23 UTC
Thoughts on VM
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
Re: Thoughts on VM
Posted by Steve Blackburn <St...@anu.edu.au>.
> 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?
Yes. This is what already happens in Jikes RVM. The most performance
critical examples are the barriers and allocation sequences, which the
optimizing compiler gets to inline and then optimize in context. As I
said in an earlier post, these dynamic optimizations can lead to the
Java implementation of the allocator out-performing highly tuned C
allocators (important since Java programs tend to be allocation
intensive). This is an argument for implementing the VM in Java.
Other elements of the VM such as the garbage collector and the
compiler/s may not benefit so much from adaptive compilation since they
are monolithic and their behavior tends to be so predictable.
--Steve
Re: Thoughts on VM
Posted by FaeLLe <mr...@gmail.com>.
Now that is a very nice point of view i had never thought of it from that
angle.
Thank you.
On 5/12/05, Bob Griswold <bg...@terracottatech.com> 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
>
>
> On 5/11/05 6:49 PM, "Kev Jackson" <ke...@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
> >
>
> --
>
>
--
www.FaeLLe.com <http://www.FaeLLe.com>
Re: Thoughts on VM
Posted by Bob Griswold <bg...@terracottatech.com>.
I totally agree with you, Steve. This is probably the biggest area of
potential win in integrating the VM into the OS.
On 5/11/05 10:23 PM, "Steve Blackburn" <St...@anu.edu.au> wrote:
> Bob Griswold wrote:
>
>> GC efficiency is very different than the speed at which the JVM runs it's GC
>> code.
>>
>>
>>
> In my experience both the GC algorithm (Bob's "GC efficiency") and the
> performance of the key GC code (Dmitry's point) are important. Having
> developed a high performance GC core (Dmitry's point), we have spent
> most of our time developing better GC algorithms (Bob's point). ;-)
>
> However, I think Dmitry's post highlights an important trend. Memory
> performance is very important and architectural trends point to this
> becoming more and more the case in the future (the relative cost of a
> memory access and the relative advantage of locality is increasing all
> the time).
>
> --Steve
--
Re: Thoughts on VM
Posted by Steve Blackburn <St...@anu.edu.au>.
Bob Griswold wrote:
>GC efficiency is very different than the speed at which the JVM runs it's GC
>code.
>
>
>
In my experience both the GC algorithm (Bob's "GC efficiency") and the
performance of the key GC code (Dmitry's point) are important. Having
developed a high performance GC core (Dmitry's point), we have spent
most of our time developing better GC algorithms (Bob's point). ;-)
However, I think Dmitry's post highlights an important trend. Memory
performance is very important and architectural trends point to this
becoming more and more the case in the future (the relative cost of a
memory access and the relative advantage of locality is increasing all
the time).
--Steve
Re: Thoughts on VM
Posted by Bob Griswold <bg...@terracottatech.com>.
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" <dm...@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" <ke...@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
>>>
>>>
>>>
>>
>>
>>
>
--
Re: Thoughts on VM
Posted by Dmitry Serebrennikov <dm...@earthlink.net>.
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" <ke...@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
>>
>>
>>
>
>
>
Re: Thoughts on VM
Posted by Bob Griswold <bg...@terracottatech.com>.
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
On 5/11/05 6:49 PM, "Kev Jackson" <ke...@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
>
--