This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: java aliasing rules
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Thu, 4 Apr 2002 23:05:49 -0500 (EST)
- Subject: Re: java aliasing rules
On Fri, 5 Apr 2002, Bryce McKinlay wrote:
> Turning it off (although note that currently it isn't *on* in the first
> place ;-) should be as simple as turning off -fnon-call-exceptions. Then
> dereferences won't have flow edges and things can be reordered across
> them. Unfortunately that will also have the side-effect of not
> generating unwind info for leaf functions.
Well, sure... leaf functions have no use for unwind info if they will
never throw.
> I'd actually be fairly surprised if you were able to measure any large
> difference in performance between the two. Note that hopefully a
> dereference will only have an edge the first time it is dereferenced.
Agreed. It may be hard to measure all right, I find that "real" Java
programs usually suffer from other bottlenecks like synchronization or GC.
For that matter I don't know if there are any large general improvements
to be made in gcj. Most of the low-hanging fruit are gone.
> >(As an aside, it's hard to classify a "modern" processor... SPARC
> >and IA-64 are in-order, and likely to remain that way.)
> >
>
> Meaning that it doesn't do any branch prediction/speculative execution
> at all? Interesting.
Yes, but isn't there a little more to OoO than that? Like reordering
instructions to avoid data hazards and cache misses?
Jeff