Query on stacktrace management logic

[Andrew Haley]

David Holmes writes:
 > 
 > I'm somewhat baffled why Throwable's stacktrace management is implemented
 > like this:
 > 
 >   private transient VMThrowable vmState;
 >   private StackTraceElement[] stackTrace;
 > 
 >   public Throwable fillInStackTrace() {
 >     vmState = VMThrowable.fillInStackTrace(this);
 >     stackTrace = null; // Should be regenerated when used.
 >     return this;
 >   }
 > 
 >   public StackTraceElement[] getStackTrace() {
 >     if (stackTrace == null)
 >       if (vmState == null)
 >         stackTrace = new StackTraceElement[0];
 >       else {
 >        stackTrace = vmState.getStackTrace(this);
 >        vmState = null; // No longer needed
 >      }
 >     return stackTrace;
 >   }
 > 
 > Rather than the much simpler:
 > 
 >   private StackTraceElement[] stackTrace;
 > 
 >   public Throwable fillInStackTrace() {
 >     stackTrace = VMThrowable.fillInStackTrace(this).getStackTrace(this);
 >     return this;
 >   }
 > 
 >   public StackTraceElement[] getStackTrace() {
 >     return stackTrace;
 >   }

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[].

All this assumes a particular VM design, of course, but I don't think
it's atypical.

Andrew.