java vs ia64 abi exceptions

[Tom Tromey]

>>>>> "rth" == Richard Henderson <rth@redhat.com> writes:

rth>   struct S { ~S() { throw 1; } }
rth>   void foo()
rth>   {
rth>     S s;
rth>     bar();
rth>   }

Thanks.

>> ... as monitorexit is allowed to throw.  However, compiled
>> Java code should never call terminate.

rth> Right.  But the question is, do we ever get into this situation
rth> in the C++ compiled java runtime?

Well, yes and no.

We do have a `_Jv_Synchronize' object which acquires a mutex in its
constructor and releases the mutex in the destructor.  In theory the
destructor could throw an exception...

rth> I'm guessing not, since it seems likely that you'd have run into
rth> this before.

but in practice it never actually happens.  First, the posix code
doesn't actually throw in any situation right now (this is an
oversight which will be corrected, I think in Hans'
hash-synchronization patch), and second it is defined to only throw an
exception if the mutex is not actually held by the thread.  This can
only happen if there are more unlocks than locks -- something that
never happens in ordinary Java code (outside of a compiler bug).

This scenario can in theory happen when compiling hand-written
bytecode.  If I had the time I could probably find a way to induce the
failure.

rth> So: what do you think of a "#pragma java_exceptions" or something
rth> at the top of your files?

rth>   (b) Error on exception specifications (since that's handled
rth>       completely differently in Java)

Is this where you write `int foo () throws whatever'?  (You can see
there's lots of C++, or at least C++ terminology, that I don't know.)

For now we never do this.  I haven't read up on how C++ handles this
to know if we could map Java exception specifications to C++ ones in a
natural way.

Anyway, all those effects sound ok to me.  A #pragma would be fine.
For libgcj we could put it in an implementation header (I think we
wouldn't necessarily want inclusion of "Object.h" or something to
enable this mode).  Maybe <cni.h> could enable it, though that might
require some header tweaking.

My concern here is whether we want to enable people to write code
which will be able to examine Java objects without wanting to do Java
exception handling.  Right now you can do that.  I don't know if
anybody does.  I also don't know if it is desirable.

Tom