>>>>> "Jon" == Jonathan Herriott <herriojr@gmail.com> writes:
Jon> I do not have anything specific in mind as of yet for improvements. I
Jon> am willing to help with the tree optimizers, so I will download the
Jon> source and start dissecting it. I just need to get a better idea of
Jon> how it currently works and how we want it to work.
Jon> In the mean time, is there anything specific you would like me to do?
I'm a bit afraid to scare you off by posting the whole to-do list :)
But, some of these ideas are relatively gentle introductions; other
ones are quite hairy.
I think the major thing we're interested in compiler-wise is
performance (we've got a pretty good handle on the 1.5 features, which
seems to be the other major area).
There's a lot we don't know about performance. So one place to start
would be to find things out... e.g., when Andrew looked at jonas (I
think) he found that the number one problem was the GC, and that by
reducing the number of GC roots we could dramatically improve scanning
performance.
There may be other things along these lines. I would guess that a
number of the areas for improvement here aren't really
compiler-related though.
Another thing to do would be to look at various java-specific compiler
optimizations and see how these affect performance (preferably on real
workloads). This is more speculative and experimental; a given patch
may not be worthwhile. (Not everything here would show up in a
profile, either -- sometimes the problems are distributed around the
generated code.)
There are a number of things that we know we could do -- some of which
are even relatively easy in some cases -- but which we've simply never
had the time to try out.
* Devirtualization. I have a patch that does this in some simple
cases. It can devirtualize and also lower interface dispatch to
virtual dispatch in cases where extra information about the runtime
type of the receiver object is available. This patch is a bit
buggy, which is one reason I haven't submitted it.
* Array bounds checking elimination. I've got a partial pass to do
this as well.
* Type check elimination. Here's a PR describing the various cases
where this would be useful.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15525
* Better class initialization removal. For the C++ ABI we could
probably do a little more work (perhaps requiring some runtime
changes) and make it possible to remove a number of class
initializations. This may give a boost in some places in libgcj
(perhaps small ... we really don't know)
We could even go one better and promise that certain core classes
will never need explicit initialization (perhaps by initializing
them during startup) and then put this knowledge into the BC ABI.
* A harder thing would be to noticeably speed up exception handling.
Andrew is really the expert here. This shows up in profiles...
* The holy grail would be to allow a copying GC somehow.
We think this is very, very hard.
* Also see http://gcc.gnu.org/wiki/GCJ_Optimization_Ideas
I can send both or either of my existing optimization passes to you if
you want to hack on them. There's some worry that we will have
difficulty getting them in, since GCC is moving toward a model where
nothing is language-specific ... but that is something we can figure
out once we have an actual commit-worthy patch.
Another compiler-ish thing we're looking at from time to time is JIT
integration. We've got some basic stuff here (an LLVM-based JIT
compiler), but we're stuck waiting for LLVM's exception handling to
match ours. Once this is more ready we'll need to be looking at
runtime optimizations and other heuristics... probably we can steal
ideas from other existing JITs.
Tom