harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: performance of drlvm
Date Fri, 28 Jul 2006 01:10:28 GMT
There was a paper last year at OOPSLA about similar things, Adam Welc 
was one of the authors.  Sounds like this may be the same work that 
Stefano is talking about.

cheers

zouqiong wrote:
> Hi, Stefano
>       I think your idea about to keep a profile for the next run of the
> same software is a
> good idea. We, people, here always talk about this idea. But in fact, 
> few vm
> implements
> this idea, i am curious about it.
>
>
> 2006/7/28, Stefano Mazzocchi <stefano@apache.org>:
>>
>> zouqiong wrote:
>> > I am very happy to know a person who has a common goal with me :-)
>> >
>> > en, my research focus on how to get more useful information to guide
>> > compile
>> > thread
>> > and garbage collector to optimize the data locality and code quality,
>> > and my
>> > interest
>> > is how to use performance monitor to get profile , and i think few
>> vitural
>> > machine use the performance monitor to guide code optimization
>> > automatic. Of
>> > course, many paper
>> > use PMU to guide the analysis.
>>
>> There is one interesting trick that I learned at an IBM presentation
>> that was done at MIT last year (apologies, I don't remember the name of
>> the speaker) about the trick of "persisting" the runtime optimization
>> information that the JVM discovers after the first few runs of a
>> particular program.
>>
>> For server side software, the warm-up time is not a big deal, but for
>> client side software, it's a huge deal if Eclipse (or your, ehm, firefox
>> extension written in java <grin>) starts up in 0.5 seconds instead of 5.
>>
>> The idea, basically, is that the *very first* time an application is
>> run, the JVM will profile it and optimize the bytecode -> native
>> compilation and go on doing its normal hot-spot stuff... but then every
>> now and then, or at shutdown, the JVM will write that info on disk, so
>> that it will be possible for the *next* run to start with a
>> "optimization profile" that is, so-to-speak, precompiled and doesn't
>> have to be inferred from the runtime execution of the program.
>>
>> There are some issues with the approach, but I think it's a great idea
>> and nothing that we, as a community, can't find an answer for.
>>
>> BTW, would be great to have those people here talking to us about those
>> new JVM tricks they are doing in IBM for J9.
>>
>> -- 
>> Stefano.
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message