libjava status on Tru64 UNIX V5.1

Fri Mar 22 17:32:00 GMT 2002

>>>>> "Bryce" == Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:

Andrew> Yes, but -fcheck-references doesn't require
Andrew> -fnon-call-exceptions, which also has fairly serious
Andrew> consequences for every method.
That's interesting. I don't think we disable -fnon-call-exceptions
when -fcheck-references is given. Right now in fact we seem to force
them to be on in java_init_options(). Should we change this?
Bryce> In theory non-call-exceptions could inhibit some optimizations,
Bryce> but in practice based on my testing there is *no* difference in
Bryce> generated code (on PowerPC at -O2) for either C++ or Java from
Bryce> changing this flag, except for extra unwind tables being
Bryce> generated for leaf functions.
That's interesting.
Bryce> -fcheck-references on the other hand results in a ~20 - 40%
Bryce> performance hit on scimark and sieve, plus substantially
Bryce> increased code size.
Ideally we'd focus our efforts on making Dwarf-2 exceptions work well
for us everywhere. Then we can reserve -fcheck-references for
MMU-less platforms, and we don't need to use sjlj exceptions. I think
using the latter is problematic because it puts us at odds with the
desired C++ default; system integrators will most likely always pick
Dwarf-2 over sjlj.
Bryce> Even if -fnon-call-exceptions did cause pessimisation (eg
Bryce> inhibiting code motion), I don't see why -fcheck-references
Bryce> won't do this as well. The EH edges are still going to be
Bryce> there because you have the possibility of a branch to a throw
Bryce> at every dereference.
Some of the tests could be optimized away or scheduled with the rest
of the code. Also I suppose tests could be hoisted out of loops,
violating the Java language standard (unless we prevent this; I don't
think we do). Of course, ideally -fnon-call-exceptions could somehow
recognize that some dereferences in fact can't generate a failure.
(I don't know whether any of these optimizations happens right now.)
Tom