[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Query on stacktrace management logic
From: |
Robert Lougher |
Subject: |
RE: Query on stacktrace management logic |
Date: |
Sat, 28 Feb 2004 20:53:03 +0000 |
Well, if it's of any interest, JamVM takes advantage of this. When
VMThrowable.fillInStackTrace() is called I store the backtrace in a compact,
internal format. Then, if and when getStackTrace() is called I convert this
into StackTraceElements. Remember, unless you do something like
printStackTrace in your catch block the StackTraceElements will never be
needed. Creating them up front will greatly increase the cost of
throwing/catching exceptions as Andrew stated.
As to your point about out of memory. Surely you _want_ the stacktrace if
it all possible? You may not be able to satisfy an allocation request but
still be able to construct an OutOfMemoryException. If you use the scheme
above, constructing the backtrace shouldn't use much memory. If the
stacktrace is printed, _lots_ of memory will be required but by this stage
it's been caught, (or more likely printed as an uncaught exception) so lots
of frames have been popped, enabling lots of memory to be collected.
If we can't construct an OutOfMemoryException, as a last resort, JamVM
throws an "empty" OutOfMemoryException pre-allocated at VM startup.
Hope this helps,
Rob.
P.S. What is your system?
----Original Message Follows----
From: "David Holmes" <address@hidden>
To: "Andrew Haley" <address@hidden>
CC: classpath <address@hidden>
Subject: RE: Query on stacktrace management logic
Date: Sat, 28 Feb 2004 10:59:01 +1000
Andrew Haley wrote:
> 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[].
Thanks - I see now. Unfortunately in our system (at present) this is not the
case. But now I have an idea of how to change that.
I still need a hook to not get the stacktrace filled in for
OutOfMemoryError - though perhaps I can do something without requiring
allocation using a different approach.
Thanks again.
David Holmes
_______________________________________________
Classpath mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/classpath
_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo