Updated ARM Spec
David Holmes
David.Holmes at oracle.com
Mon Aug 23 02:35:59 PDT 2010
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.
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 coin-dev
mailing list