Re: Patch: replace mutex with object synchronization

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:

Andrew> I guess I don't really agree with Tom about this.  I can see
Andrew> no obvious reason why we should ever want to compile java.*
Andrew> using indirect dispatch, and at least one strong efficiency
Andrew> reason why we shouldn't.

I think the reasons have to do with development of libgcj itself more
than anything.

First, BC would make it simpler for us to split libgcj into pieces.
This has some nice impacts in terms of the time it takes to build
libgcj, and probably other benefits.

Second, while people work on gcj, it is convenient to be able to
replace core classes.  E.g., Graydon and Tom have complained that
working in libgcj is a difficult way to develop AWT and Swing, because
the development cycle is too long.  If you could just compile to
bytecode and point libgcj at it, this would go away.

It would be very convenient for development to be able to point libgcj
at an unmodified copy of Classpath (and have just a few core classes
come pre-compiled).  I don't expect anybody will seriously pursue
this, unfortunately.

Also for org.w3c.* (still part of libgcj, though we don't often
remember them...) we definitely want the BC ABI, since it isn't
uncommon for other projects to ship these.  I've run into weird
problems with this more than once.

I do agree that if libgcj were complete we might not need to use the
BC ABI for it.  We're a long way from that.

Tom