On the 0x198 day of Apache Harmony Rana Dasgupta wrote:
> On 22 Jun 2006 16:16:24 +0700, Egor Pasko <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
