Updated ARM Spec (original) (raw)

Rémi Forax forax at univ-mlv.fr
Mon Aug 23 03:15:42 PDT 2010

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

Remi,

I think there is some confusion over the use of pre-allocated exceptions here. For OutOfMemoryEror we have two kinds of pre-allocated exceptions for the general case of exhausting the Java heap. First we have PreallocatedOutOfMemoryErrorCount (default 4) OOME instances, which have space for a backtrace allocated. These instances can only be thrown once and so can only have one real backtrace. Of course application code can mutate that stacktrace but that won't affect any other point where OOME is thrown as it won't be that OOME. In addition there is one preallocated OOME instance that has no backtrace allocated for it. Hence when it gets thrown no backtrace is filled in and there is nothing for the application code to mutate. This single instance can be thrown by multiple threads in multiple circumstances without harm.

Here is the bug, the application can mutate the default OOME using setStackTrace().

Similarly there are a bunch of pre-allocated OOME objects, without backtraces, for special conditions like maximum array size being exceeded etc. None of the other special pre-allocated instances (NPE, ArithmeticException, ...) have a backtrace either. So there is no need for the VM to clear the backtrace before throwing any pre-allocated exception instance. 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. Aside: StackOverflowException is created on demand, not pre-allocated, in Hotspot. David Holmes ------------

Rémi

More information about the coin-dev mailing list