This is the mail archive of the java-discuss@sourceware.cygnus.com mailing list for the GCJ project. See the GCJ home page for more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: synchronization in gcj


 Jerry,

> 
> If the exception handling is badly structured (in terms of mapping of
> bytecode ranges to handlers) then it is possible to miss execution of
> monitorexit before returning from the method.  This bug is present in both
> bytecode produced by Sun's javac, and also IBM's jikes.

I didn't know about this.  Can you give an example of or pointer to code
that javac or jikes mishandles?

The convention that monitor_exit be placed in exception handling code
is one that the compiler is supposed to guarantee, but the verifier won't
enforce it, will it?

About your argument that a robust runtimes should unlock all locks held
in a method --- I am not sure if that argument holds up.  Isn't this like
saying that the run-time should silently fix errors made by the compiler?

And if the verifier does indeed *not* check the symmetry of exit and enter,
what's to prevent a programmer from creating bytecode like :

    lock() {
	    MONITOR_ENTER
    }
    unlock() {
	    MONITOR_EXIT
    }

If that bytecode passes the verifier, the run-time should run it, should
it not --- even in the face of exceptions.

	- Godmar