libjava status on Tru64 UNIX V5.1

Mon Mar 25 01:25:00 GMT 2002

Tom Tromey writes:
 > >>>>> "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?
It depends on what we do with divide overflows, but in general yes.
 > 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.
It is. The pessimization caused by non-call-exceptions looks more
like a theoretical than a practical problem, at least with the current
PowerPC target.
 > 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.
Exactly right.
 > 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.
Totally, yes.
 > 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.)
I remind my learned friend of the front-end patch I mentioned
earlier... :-)
But seriously, the front end knows a great deal about what references
might trap, *and* can be improved to know a lot more.
Andrew.