Updated ARM Spec

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