harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [drlvm] what's next?
Date Thu, 29 Jun 2006 19:32:09 GMT
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.

>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.

>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 :-) )

>* 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 :-)

> --
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message