> On Nov 18, 2015, at 1:01 PM, Coleen Phillimore <coleen.phillim...@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
