This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: libcj java.nio.DirectBuffer is slow (no inlining)
- From: Tom Tromey <tromey at redhat dot com>
- To: pierre-olivier dot gaillard at fr dot thalesgroup dot com
- Cc: java at gcc dot gnu dot org
- Date: 06 Jun 2006 10:47:13 -0600
- Subject: Re: libcj java.nio.DirectBuffer is slow (no inlining)
- References: <44859BB9.8000608@fr.thalesgroup.com>
- Reply-to: tromey at redhat dot com
>>>>> ">" == 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