Updated ARM Spec (original) (raw)

David Holmes David.Holmes at oracle.com
Mon Aug 23 03:09:55 PDT 2010

Rémi Forax said the following on 08/23/10 20:06:

Le 23/08/2010 11:50, David Holmes a écrit :

I said the following on 08/23/10 19:35:

... The "suppressedException" array as I currently understand it would need to be cleared, if the pre-allocated instances with no backtrace can still contain "suppressedExceptions" - which I believe they can.

I just realized however that clearing the suppressed-exception state is simply not an option as the same exception instance could be thrown concurrently in multiple threads. In short these shared immutable exception instances must remain immutable if they are to be shared. Hence they can not contain suppressed-exception information. David Holmes PS: I am not a subscriber to coin-dev. You can explicitly call setStackTrace() on a shared immutable exception, hence there is a problem. addSupressedExceptions() will have the same issue.

I stand corrected. The Java side of the code couldn't care less about the VM level backtrace - it just installs a Java array. :(

I think the fix is to: - silently discard the stack trace taken as argument of setStackTrace() if the cause is 'null' (or not 'this') - silently don't register suppressed-exceptions if cause is 'null'

I think the Java code should be able to recognize a Throwable instance that should not allow these things to be set, and simply ignore the request. However that is a change in the spec for setStackTrace.

Suppressed-exceptions could then be modelled like backtrace support - an optional facility generally used but ignored for the pre-allocated immutable instances.

David

Rémi

Aside: StackOverflowException is created on demand, not pre-allocated, in Hotspot. David Holmes ------------

Rémi Forax said the following on 08/13/10 22:41: Le 13/08/2010 05:28, Neal Gafter a écrit : When a stack overflow exception suppresses another exception, I assume it's suppressed exception list will be set. But since there is only one such exception allocated by the VM, this will overwrite any data previously stored there. Will the VM be modified to comply with this specification by allocating a new stack-overflow exception each time? Same question for out-of-memory error. This problem already exists with jdk6. This code change the stack trace of permanently allocated OutOfMerroryError. public static void main(String[] args) { Error last = null; for(int i=0; i<100; i++) {_ _try {_ _Object o = new int[Integer.MAXVALUE];_ _} catch (Error e) {_ _StackTraceElement[] stackTrace = e.getStackTrace();_ _if (stackTrace != null && stackTrace.length>0 && stackTrace[0].getLineNumber() == -3) { e.printStackTrace(); return; } if (last == e) { StackTraceElement element = new StackTraceElement("Foo", "foo", null, -3); e.setStackTrace(new StackTraceElement[]{element}); } last = e; } } }

To avoid that the VM has to clear the stacktrace when using the default error: in universe.cpp, in Universe::genoutofmemoryerror: if (next < 0) { // all preallocated errors have been used. // return default + javalangThrowable::clearstacktrace(defaulterr); return defaulterr; } else { And we should do the same for the field suppressed exceptions. Rémi

More information about the coin-dev mailing list