gcj performance on Solaris 2.6

Bryce McKinlay bryce@waitaki.otago.ac.nz
Thu Jul 26 18:33:00 GMT 2001

Jeff Sturm wrote:

> On 26 Jul 2001, Tom Tromey wrote:
> > If you are running performance tests, always use at least -O1.
> > -O2 is probably better.  Often, -O3 can give worse results than -O2,
> > though, because (I hear) it inlines too aggressively (perhaps not a
> > problem for Java, where inlining is still not quite there).
> True.  Gcj has a different problem: every private/static/final method is
> declared DECL_INLINE.  That may not always do what you want.
> I built one application library at -O0, -O2 and -O3 with the patch below,
> and at -O2 unpatched for comparison.
>    text    data     bss     dec     hex filename
> 1659369  247180     704 1907253  1d1a35 libjacl-O0.so
> 2474525  243612     704 2718841  297c79 libjacl-O2-unpatched.so
> 1354881  237836     704 1593421  18504d libjacl-O2.so
> 1418826  236272     704 1655802  1943fa libjacl-O3.so
> With the patch -O2 yields the smallest binary, and -O3 slightly larger.
> That's what I expect.  But the unpatched gcj nearly doubles the text size
> at -O2.  The library built with -O3 executes fastest on my tests.
> I'd be inclined to omit DECL_INLINE in the frontend and let the integrator
> use its best judgement, at least until we have tree inlining with decent
> heuristics.  Of course one application on one platform isn't a good
> data set.  Comments?

Wow. It would be interesting to see what sort of difference it makes to the
size of libgcj with this patch applied. If its as significant as this, and
the performance difference isn't big, then I would vote in favour of applying
it until the front end can be made smarter about inlining. At -O3, I suspect
it is inlining functions even when they do not have DECL_INLINE set? Perhaps
then we should consider building libgcj with -O3, or whatever option tells it
to inline more aggressively?



More information about the Java mailing list