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

Tue Jun 6 17:20:00 GMT 2006

Sorry for leaving the list off of my previous reply. It will not happen 
again...
Andrew Haley wrote:
> 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?

There is an inheritance hierarchy so not all of them could be final. 
However all the constructors are private, so the compiler/runtime can 
take advantage of the fact the there will never be any derived Buffer 
classes.
>> > Given knowledge of the runtime library, inlining would not be much
> > different than for things in java.lang.Math.
>> Andrew.