This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: dynamic library cost (was RE: libtool, java woes)
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: dynamic library cost (was RE: libtool, java woes)
- From: Tom Tromey <tromey at redhat dot com>
- Date: 12 Apr 2001 23:19:46 -0600
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, "'Alexandre Oliva'" <aoliva at redhat dot com>, Jeff Sturm <jsturm at one-point dot com>, java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- References: <140D21516EC2D3119EE7009027876644049B5D4C@hplex1.hpl.hp.com> <3AD3B055.2F232BD9@albatross.co.nz>
- Reply-To: tromey at redhat dot com
>>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:
>> I'm seeing significant overheads as a result of dynamic library
>> calls. On a PII/300 machine, a (single-threaded) loop containing
>> only free(malloc(8)) runs more than 20% faster when it's linked
>> statically. This is similar on an Itanium machine. I'm not sure
>> how significant that is for typical C programs, nor how frequently
>> something like libsupc++ is called. I believe it is currently very
>> significant for libgcj and calls to the garbage collector library
>> from libgcj.
Bryce> Why don't we link the garbage collector into libgcj?
There's no particular reason right now. Eventually I think the GC
will be runtime configurable so that different applications can use
the same .so. The idea then was that it would be used as a pure
shared library.
Still I don't think that is super-compelling for us. I'd prefer to
have measurements before changing it.
Tom