This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: replace mutex with object synchronization
- From: Jeff Sturm <jsturm at one-point dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Bryce McKinlay <mckinlay at redhat dot com>, Anthony Green <green at redhat dot com>, <java-patches at gcc dot gnu dot org>
- Date: Mon, 19 Apr 2004 21:14:43 -0400 (EDT)
- Subject: Re: Patch: replace mutex with object synchronization
On Mon, 19 Apr 2004, Andrew Haley wrote:
> > > I suspect there will always be a few classes we don't compile with the
> > > BC ABI. Object, maybe Class and String too. This seems like an area
> > > we need to experiment with once the patches are in.
> >
> > Yeah. At one time I successfully compiled most of libgcj with
> > -fno-assume-compiled. Except java.lang.Class; I don't remember why but it
> > did not work.
>
> I guess I don't really agree with Tom about this. I can see no
> obvious reason why we should ever want to compile java.* using
> indirect dispatch, and at least one strong efficiency reason why we
> shouldn't. If anyone knows how using indirect dispatch will make the
> core libgcj work better, I'm upen to being persuaded.
I tend to agree for java.lang, most of which can't be safely replaced at
runtime.
When I ran the -fno-assume-compiled experiment I was simply trying to
link as small an executable as possible. Efficiency wasn't important. I
ran the application once printing the name of each class as it was loaded,
and then relinked exactly that set of classes (a hundred or so). The
final executable was around 800KB.
Jeff