Re: Patch: replace mutex with object synchronization

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "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.

Yeah, but that's not the core: Swing is not in java.*.  I'm not
arguing that things outside java.* should not use the BC ABI.  But
things that are in the core should be compiled as much as possible so
that we don't have to do any work at startup.

Now, if we go over entirely to pointer-free symbolic class data in
object files then we'll need to do _some_ work at startup.  But let's
make it as little as possible, OK?  :-)

Andrew.