This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: -O2 loop problems
- To: Tom Tromey <tromey at redhat dot com>
- Subject: Re: -O2 loop problems
- From: Jeff Sturm <jsturm at detroit dot appnet dot com>
- Date: Tue, 26 Dec 2000 10:20:41 -0500 (EST)
- cc: "green at cygnus dot com" <green at cygnus dot com>, "'java-discuss at sources dot redhat dot com'" <java-discuss at sources dot redhat dot com>
On 25 Dec 2000, Tom Tromey wrote:
> If you've got any profiling info I'd love to see it. I don't really
> have a feeling for what bottlenecks might exist for real applications.
Not yet. We still don't have a good way to profile multithreaded
code. Somebody (AG?) on this list once posted a link to a tool, but I had
trouble building it.
If I get a chance this week I'll power up my Alpha again, which has been
hibernating during the move. It has hardware performance counters. I
don't expect quite the same results on a totally different architecture,
but the nice part of hardware counters is very low overhead. Plus they
don't care about multithreading. It should help to find bottlenecks that
apply to other architectures as well.
I'd be able to compare with Compaq's new JDK for Alpha/Linux, which
supposedly has a JIT.
If I were to guess I'd say one of the next major hurdles will be method
inlining. If I had the time and ability to work on the frontend, here's
what I would try:
1) Turn on method-at-a-time code generation in the bytecode compiler
2) Add tree-based inlining to the bytecode compiler
3) Add tree-based inlining to the source compiler
My hunch is that starting with the source compiler would limit its
usefulness since there are many opportunities for inlining when source is
not available, e.g. invoking String.length() from user code.
Jeff