harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] what's next?
Date Fri, 30 Jun 2006 02:32:08 GMT
On the 0x198 day of Apache Harmony Rana Dasgupta wrote:
> On 22 Jun 2006 16:16:24 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
> >
> > >Addressing JIT changes, I would suggest some short-term
> > >iprovements/projects that are interesting to do to quickly catch up
> > >with DRLVM optimizing JIT(s):
> >
> > >* Devirtualization improvements
> >
> > >Currently DRLVM does *not* devirtualize interface calls.
> >
> > >A not-so-quick hack for the start: make a class-test based on the
> > >class that
> > >a) implements the interface
> > >b) has the the method invoked with some instance (first invocations are
> > >easy to register in JIT since they initiate compilation phase)
> Sounds look a sensible first approach. It would be good to find a micro or a
> workload that we can use to demonstrate the existence of the interface
> virtual method call perf problem, and then the improvement.

OK, that's a good point. I'll try to reach this kind of a workload.
Does a microbenchmark make sense to find it's place in JIRA?

> >In future, a more sophisticated heuristic would be interesting to
> > >experiment with. Ideas?
> >
> > >* Back-Branch-Polling (BBP) improvements
> >
> > >BBP is an optimization pass that inserts extra helper-function-calls
> > >(safepoints) in loops to make them interruptable
> > >(suspendable). Necessary for Thread::stop() and quick response to
> > >GC.
> >
> > >In DRLVM BBP introduces an overhead about 1-2% (on single-threaded
> > >workloads), which could be optimized out. Currently, backedges are
> > >polled for non-interruptable loops. We could detect finite loops and
> > >poll them more wisely.
> Same suggestion, it would be nice to acquire this single threaded workload(
> SpecJVM?) that demonstrates this 1-2% loss first.

Hm, a subject to find out too..

> >BTW, Jrockit sometimes forgets about polling. Harmony should be better.
> > >Yet, we can turn BBP off with a quick experimental option:
> > >      -Xjit ia32::bbp=off{0},jet::no_bbp=true
> Where are you proposing this optimization? Does the BBP exist in the DRLVM
> codebase in the .JET jit only ? (Why two flags to turn it off, BTW :-) )

Two flags: first for Jitrino.OPT, second for Jitrino.JET
It is Jitrino.OPT that needs the improvement since JET has too little
opportunities to optimize like that.

> >* Over-synchronization removal
> >
> > >Nested synchronization blocks on the same object can be removed. Not
> > >done in DRLVM yet.
> It would be good to identify some broader Harmony goals/targets at some
> point ...other than compatibility and functional completeness. Eg., where do
> we want to be as compared to RI or other VM's in performance,
> responsiveness, etc.? For example BBP above can be seen as a
> responsiveness optimization, so it may be OK even if it shows no perf
> gain, ie., if the optimization can just eliminate the loss. Depends on where
> we want to go.... Initially of course any improvement is good :-)

OK, I know, we need a set of corresponding benchmarks for that too :)

BTW, responsiveness has it's impact on performance when we run
multithreaded code. So, we can talk only about performance on certain
workloads (and, yes, certain hardware...)

Egor Pasko, Intel Managed Runtime Division

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

View raw message