Stack traces are used by the Throwable class, security checks, calling-classloader lookup, and reflection accessibility checks. However, the current implementation is not conductive to supporting all these uses in an efficient manner. It needs to be refactored and improved. Specifically: - libgcc's unwinder machinery should be used instead of backtrace() - allocation during stack tracing should be avoided where possible - for security/classloader/accessibility checks, we should only walk the stack as far as needed to complete the check, not the entire stack - native "RawData" pointers should not be passed around in Java code The idea is to put common stack-trace infrastructure - code used for both exceptions and security - in a stacktrace.cc or something similar. natVMThrowable will use that and StackTrace.java etc will go away.
- libgcc's unwinder machinery should be used instead of backtrace() This is probably true, but it may be slower. - for security/classloader/accessibility checks, we should only walk the stack as far as needed to complete the check, not the entire stack I don't understand this. We don't walk the entire stack at the moment.
Isn't this fixed in 4.1?
Yes. This is fixed in GCC 4.1.