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

[David Daney <ddaney at avtrex dot com>]

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.