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: Andrew Haley <aph at redhat dot com>
- To: Jeff Sturm <jsturm at one-point 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:11:53 +0100
- Subject: Re: Patch: replace mutex with object synchronization
- References: <8765c3abdx.fsf@fleche.redhat.com><Pine.LNX.4.44.0404191557260.19041-100000@ops2.one-point.com>
Jeff Sturm writes:
> On 13 Apr 2004, Tom Tromey wrote:
> > Bryce> I guess it doesn't matter right now, since libgcj itself isn't
> > Bryce> built with the BC-ABI, but eventually, using Java locks here
> > Bryce> could potentially lead to circularity problems.
> >
> > 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.
Andrew.