This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Correction to last message, GC status
- To: "'tromey at redhat dot com'" <tromey at redhat dot com>, Jeff Sturm <jsturm at one-point dot com>
- Subject: RE: Correction to last message, GC status
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- Date: Tue, 26 Jun 2001 09:32:33 -0700
- Cc: "Boehm, Hans" <hans_boehm at hp dot com>, java at gcc dot gnu dot org
I suspect that we'll also see a measurable performance increase from linking
statically linking the GC library against libgcj. Allocation calls from
inside libgcj (e.g. for strings) will no longer cross a dynamic library
boundary. So long as gcc doesn't generate direct GC_ calls, we'll reduce
the number of boundary crossings for allocation from 2 to 1.
Hans
> -----Original Message-----
> From: Tom Tromey [mailto:tromey@redhat.com]
> Sent: Monday, June 25, 2001 8:10 PM
> To: Jeff Sturm
> Cc: Boehm, Hans; java@gcc.gnu.org
> Subject: Re: Correction to last message, GC status
>
>
> >>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:
>
> Jeff> What is the advantage of building libgcjgc as a shared lib? Or
> Jeff> libzgcj for that matter? We don't have pluggable GC, and
> Jeff> libzgcj isn't any different from libz.so (or is it?).
>
> There probably isn't a benefit.
>
...