I'm new and wanting to help!

[Jonathan Herriott]

> I'm a bit afraid to scare you off by posting the whole to-do list :)

Unfortunately, I don't get scared off easy :P

If you could send me both of those optimization passes, that would be
terrific.  I'll look at them and see if I can do anything.  If not,
I'll figure it out :)

Jon

On 02 Aug 2006 16:20:29 -0600, Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "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
>