classpath
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]