[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Query on stacktrace management logic
From: |
Andrew Haley |
Subject: |
Query on stacktrace management logic |
Date: |
Fri, 27 Feb 2004 11:46:47 +0000 |
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.