Unconditionally skipping some special frames in the stack trace may also make language implementers' lives hard when they're *developing* - it's analogous to when JVM implementers want to see all frames of a stack, including the native/VM internal ones, where as most Java developers would just want Java frames.
There are scenarios where unconditionally skipping some frames should always be good, like skipping some internal frames with regard to security checking, especially when such behavior is required by related specs. - Kris On Thu, Jul 12, 2012 at 5:11 PM, John Rose <john.r.r...@oracle.com> wrote: > On Jul 10, 2012, at 2:12 AM, Rémi Forax wrote: > > I think backtrace filtering, should be enhanced by adding a new method > attribute in the bytecode that indicates if a method should be visible > or not > when dumping a stacktrace and a display name that should be used > instead of the bytecode method name. > > This may reduce the need of stacktrace post-processing and makes Charles > happy. > > > I'm don't think we've identified a sweet spot yet, but I encourage people > to experiment. Eventually such a thing could make its way into a JSR > (maybe in a MR). > > One problem with mixed mode systems is that a method like > "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a > method name based on some value inside the frame itself. Simply filtering > or renaming JVM methods does not cover this case at all. > > — John > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > >
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
