Code Review for JEP 259: Stack-Walking API

[Mandy Chung]

> On Nov 18, 2015, at 1:01 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> One of the things that I'm struggling with is that StackFrameInfo contains both the collected information from walking the stack frames, method id, bci, mirror, version and cpref, and the digested information: interned string for class name, method name, line number and source file name.
> 

method id, mirror, version and cpref are injected in StackFrameInfo.  I hope there is a way to make it conditional only if -XX:-MemberNameInThrowable is set (is it possible?)

-XX:-MemberNameInThrowable is temporary and disabled by default.  It is used for follow-on performance improvement as we discussed previously.   I still believe that there may be some low hanging fruit to reduce the initialization of MemberName for an already-linked method.    We should aim to remove this flag in JDK 9 so that StackFrameInfo will have only MemberName and bci.

The interned string for class name, method name, line number and source file name are requested lazily when StackFrame::getMethodName or other methods are called.  They are not eagerly allocated.

> If this is to replace stack walking for exceptions, this will more than double the footprint of the information collected but rarely used. I don't understand why the digested information isn't still StackFrameElement?
> 

If Throwable uses StackWalker, I expect it to use MemberName and -XX:-MemberNameInThrowable should be removed by that time.   Also VM no longer needs to fill in StackTraceElement as it should fill in StackFrameInfo.   java_lang_StackTraceElement in javaClasses.[hc]pp can be removed at an appropriate time :)

Throwable backtrace will keep an array of StackFrameInfo, one element per frame.  StackFrameInfo only captures the MemberName + bci.  When Throwable::getStackTraceElements() or printStackTrace() is called, the VM will allocate the intern strings for those names and fill in StackFrameInfo.  Then convert them to StackTraceElement[] and throw away StackFrameInfo[].   This is just the current implementation.   I expect further optimization can be done in the JDK side about StackTraceElement and StackFrameInfo.

> That's just a high level comment.  I haven't read the java code yet for the rationale why this type is used for two different things.
> 

The way I implement it is to prepare Throwable backtrace + StackTraceElement be replaced by StackFrameInfo in the VM.

The VM fills in StackFrameInfo for StackWalker.   When Throwable switches to use StackWalker, VM doesn’t need to know anything about StackTraceElement.

Mandy