RE: dynamic library cost (was RE: libtool, java woes)

["Boehm, Hans" <hans_boehm at hp dot com>]

I'd like to move in a slightly different direction.  I'd like to see gcc
generate code that calls GC_gcj_malloc directly in most cases, at least for
non-embedded applications.

In 3.0,the allocation path is _Jv_AllocObject (prims.cc) -> _Jv_AllocObj
(boehm.cc) -> GC_gcj_malloc (GC library).

In my version _Jv_AllocObj is simply an inlined call to GC_gcj_malloc, so
this path is a little shorter, but still too long.

_Jv_allocObject currently does the following:

1) Calls _Jv_InitClass.  This normally involves an inline test of a global.
It seems to me the compiler should be doing this (perhaps even in the
embedded case?) since it can often (usually?) be optimized out.  Much of the
overhead is in locating the global, and that could be moved out of loops,
etc.

2) Checks if a finalizer needs to be registered, and does so if necessary.
This is a very expensive  (5 + memory references?) test for something that I
believe is completely statically known.  The test should definitely be done
by the compiler.  (It can still call through libgcj if a finalizer needs to
be registered.  That's currently fairly expensive anyway, and it's
relatively infrequent.)

3) If object allocation notifications are requested, it does some messy
JVMPI allocation profiling stuff.  I think this is currently compiled in by
default?  I don't understand the full history or current status here, but
I'd be inclined to turn it off by default.  (As far as I undertand it, it's
advantage is that it's semistandard.  It's disadvantages are that neither
the spec nor the implementation look quite right (the stuff about turning
off GC looks wrong to me), it looks very intrusive for a profiling
mechanism, and I think there are usually better mechanisms for answering the
questions I would really want answered.)

4) It calls _Jv_AllocObj (which does nothing but call GC_gcj_malloc).

A disadvantage of this change is that it would create a direct dependency
from gcj generated code to the GC library.  But I suspect that's already
implicitly there, since another GC library would probably need a compiler
write-barrier, etc.

I'm trying to generalize the GC library, so that a single binary could be
used for Java, C, ObjC, etc.  So I would like to avoid replicating it in
libgcj.  It may still  make sense to replicate the top level routines, if
there's a clean way to do that.

Hans

> -----Original Message-----
> From: Bryce McKinlay [mailto:bryce@albatross.co.nz]
> Sent: Tuesday, April 10, 2001 6:16 PM
> To: Boehm, Hans
> Cc: 'Alexandre Oliva'; tromey@redhat.com; Jeff Sturm; 
> java@gcc.gnu.org;
> gcc@gcc.gnu.org
> Subject: Re: dynamic library cost (was RE: libtool, java woes)
> 
> 
> "Boehm, Hans" wrote:
> 
> > 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.
> 
> Why don't we link the garbage collector into libgcj?
> 
> regards
> 
>   [ bryce ]
> 
>