RFR (XS) 8216977: ShowHiddenFrames use in java_lang_StackTraceElement::fill_in appears broken
david.holmes at oracle.com
Thu Aug 29 01:36:04 UTC 2019
On 29/08/2019 6:25 am, coleen.phillimore at oracle.com wrote:
> Summary: Return NULL source file and negative line number for hidden
> See bug for more details. Ran hs tier1-3 on linux-x64-debug and tier1
> on all platforms.
This issue made my head spin. I think what you have done has taken
things back to a sane place where ShowHiddenFrames is not being used to
do whacky things unrelated to hidden frames.
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8216977.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8216977
Okay - this code was reporting a specially encoded "line number" that
actually contained the BCI, but only if ShowHiddenFrames was true.
Getting rid of this is good because it has nothing to do with hidden
frames and there wasn't even a check that the current frame was in fact
If we want to report the BCI when no line number table exists then that
should be a specific enhancement to the API.
Okay - this code was changing a NULL source file to "unknown" but only
if ShowHiddenFrames is true. Again getting rid of this is good as it
again has nothing to do with hidden frames.
If we want to report "unknown" rather than NULL, then we should make
that change independent of ShowHiddenFrames.
Can you add a comment explaining why String::concat meets the criteria
of "null source file" and "no line number table", as it is not at all
obvious to me what that should be the case. Also is that true if we
disable the String concatenation use of lambda? If not we should add the
necessary -XX:+ flag to the @run line.
For completeness can you check that the NPE only has one frame if
-XX:-ShowHiddenFrames is used.
More information about the hotspot-runtime-dev