Re: libcj java.nio.DirectBuffer is slow (no inlining)

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Andrew Haley wrote:
 > > P.O. Gaillard writes:
 > > 
 > >  > I am using the gcj 4.1 that came with Fedora Core 5 and the NIO
 > >  > buffers are quite slow. From what I see with Oprofile, I would say
 > >  > that this is because the code is not inlined.
 > > 
 > > It's possible.  It'd be intresting to find out.
 > > 
 > >  > Is it possible (safe, reasonable?) to compile libgcj with -O3 ? If
 > >  > so why is the libgcj in FC5 not compiled that way ?
 > > 
 > > I know for certain that it's a significant improvement for some of the
 > > crypto classes.  In general, however, we lack data to know if the
 > > additional bloat justifies the increase in size.
 > > 
 > >  > Also, I have noticed that inlining does not seem to happen with
 > >  > methods from other classes and non final methods. Am I right ?
 > > 
 > > Clearly, inlining non-final methods is impossible in any language
 > > unless you do whole program compilation or some kind of
 > > interprocedural optimization, because the methods might be overridden.
 > > 
 > 
 > Conceptually the Buffer classes are final WRT the standard runtime, as 
 > they can only be created by the factory methods.

So couldn't they simply be declared final?

 > Given knowledge of the runtime library, inlining would not be much
 > different than for things in java.lang.Math.

Andrew.