Why does java.lang.Throwable delay the StackTrace array construction?
Well consider what happens in a VM. VMThrowable.fillInStackTrace() is very fast — it’s just a chain of addresses. VMThrowable.getStackTrace() is very slow, because it has to convert all those addresses into StackTraceElements. I suspect that you can get the trace for the whole stack in less time than it takes to create a single StackTraceElement. For this reason, the vmState is stored and lazily converted to a StackTraceElement[]. (Andrew Haley) A particular problem is posed by OutOfMemoryException: throwing it shouldn’t require any memory (there’s none anyway). Some propose that the VM should preallocate it at bootstrap, but this doesn’t solve the problem. In Chris Gray’s words “if several threads throw OOME at the same time, the stack traces can get mixed up […snip…] This situation is less improbable than you might think, since if one thread encounters an OOM situation, all other threads should encounter one too. With some forms of co-operative multi-threading you may get away w
Well consider what happens in a VM. VMThrowable.fillInStackTrace() is very fast — it’s just a chain of addresses. VMThrowable.getStackTrace() is very slow, because it has to convert all those addresses into StackTraceElements. I suspect that you can get the trace for the whole stack in less time than it takes to create a single StackTraceElement. For this reason, the vmState is stored and lazily converted to a StackTraceElement[]. (Andrew Haley) A particular problem is posed by OutOfMemoryException: throwing it shouldn’t require any memory (there’s none anyway). Some propose that the VM should preallocate it at bootstrap, but this doesn’t solve the problem. In Chris Gray’s words “if several threads throw OOME at the same time, the stack traces can get mixed up […snip…] This situation is less improbable than you might think, since if one thread encounters an OOM situation, all other threads should encounter one too.
