harmony-dev mailing list archives

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