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

Tue Jun 6 17:07:00 GMT 2006

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.