Updated ARM Spec

David Holmes David.Holmes at oracle.com
Mon Aug 23 02:35:59 PDT 2010


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.

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 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.MAX_VALUE];
>       } 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::gen_out_of_memory_error:
>   if (next < 0) {
>       // all preallocated errors have been used.
>       // return default
> +    java_lang_Throwable::clear_stacktrace(default_err);
>       return default_err;
>     } else {
> And we should do the same for the field suppressed exceptions.
> Rémi

More information about the hotspot-runtime-dev mailing list