This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: java/5794: gcj fails to verify .class file generated by Sun JDK1.4 compiler


Tom Tromey wrote:
"Jesse" == Jesse Rosenstock <jmr@ugcs.caltech.edu> writes:
Jesse> As previously discussed, I commented out the check that the
Jesse> exception handler target is outside of the range of the code
Jesse> the exception handler is for.  This is not dangerous, the worst
Jesse> it could cause is an infinite loop.

Also see Andrew's pending patch to turn this into a warning.  I think
his approach makes sense, since it is unlikely that such bytecode has
a useful meaning.
This does have useful meaning, and JDK 1.4.0 and above, as well as jikes 1.16 and above, now generate such bytecode. Sun has recently begun to insist that with the synchronized statement, that ALL possible instructions until a monitorexit has successfully executed be covered by a handler. This is because an asynchronous exception might occur, but the compiler must guarantee that no exception can interrupt the release of the monitor. In short, Sun no longer follows the 2nd bullet of JVMS 4.9.5.

--
This signature intentionally left boring.

Eric Blake ebb9@email.byu.edu
BYU student, free software programmer


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