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

[David Daney <ddaney at avtrex dot com>]

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.  Given knowledge of the 
runtime library, inlining would not be much different than for things in 
java.lang.Math.

Someone should add an entry to: 
http://gcc.gnu.org/wiki/GCJ%20Optimization%20Ideas

David Daney.