This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


>>>>> ">" == P O Gaillard <pierre-olivier.gaillard@fr.thalesgroup.com> 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.

Which specific methods should be inlined but aren't?

I think for some of the buffer classes, we wanted to add compiler
support of some kind, but never got around to it.  In some cases we
can add compiler support for directly inlining certain calls.

>> Also, I have noticed that inlining does not seem to happen with
>> methods from other classes and non final methods. Am I right ?

For BC compilation we basically don't do inlining at all.  (I think
we may inline private methods but that is it.)

For the C++ ABI we can do a bit more.  And I think we do, but I
haven't looked into it much.

For non-final methods, doing inlining is tricky.  First you'd have to
do devirtualization.  I have an experimental pass for this, but it is
not ready to go in.

>> Gnat has the infrastructure to do inlining between separate
>> compilation units with -gnatn. This can bring great performance
>> improvements for code with lots of small methods. Is this feature also
>> available for GCJ ?

Nope.  Maybe when the LTO project is ready we will be able to do more
here.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]