Re: Query on stacktrace management logic

[Ingo Prötel]

Hi,

we also have a preallocated OutOfMemoryException with I think speace for about 20 stack frames in our internal representation. To throw this exception 
from the native code (where memory allocation ocurres) we use a function call that fills in the stack trace. Further we have the 
printStackTrace-Method overwritten to print the internal representation without further memory allocation.
The resulting stack trace looks somewhat different than a regular stack trace, 
but it helps in many cases.

ingo

Robert Lougher wrote:
> 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
>
>
>
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath