JDK-6175499 : Run-time compiler eliminates source line or basic-block debug info in run-time compiler.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 1.4.2_05
  • Priority: P1
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-10-07
  • Updated: 2013-11-01
  • Resolved: 2005-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b63Fixed
Related Reports
Relates :  
JDK-6379830 - JVM crash when running sun studio 11 performance analyzer
Relates :  
JDK-6359840 - Forte collector plugin misuses debug-info accessor to query backtrace
Description
When a Java app is compiled with "javac -g", information that correlates byte codes back to source lines is inserted in the class files.
When the Hotspot run-time compiler compiles some of those byte codes, that source line correlation is lost. The source-line info is needed by Sun's Collect/Analyzer tools to correlate performance information with specific lines or blocks of code. The performance information includes time spent, cache misses, TLB misses, etc. For C, C++, and Fortran, the Collect/Analyzer is incredibly useful at showing the developer what part of the code is taking the most time. For Java, Collect/Analyzer can't provide the same degree of detail. For code that is compiled at run-time, Collect/Analyzer can report only by method, not by source line.

Please preserve this line number information when code is compiled at run-time.
###@###.### 10/7/04 15:23 GMT
Comments
SUGGESTED FIX Correct. The mapping already exists for safepoints; we extended it to non-safepoints. As noted in the comments, this cannot be done exactly with optimized code, but we think the results, though approximate, are probably useful. Binaries for evaluating this fix may be found here: /net/lukasiewicz.sfbay/export/tmp/20051204215841.jrose.mustang-debuginfo/ [Note: this is a temporary location; it includes a fix to 6359840, which should appear in Mustang build b64] Please file a followup bug to track poor-quality profile information, if that proves to be a problem. http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20051201132805.jrose.mustang-debuginfo/workspace/webrevs/webrev-2005.12.01/index.html
03-12-2005
EVALUATION The stack sampling code in forte.cpp looks at debug information to interpret PCs. It gives up on the leaf frame, because only call-site PCs have debug info. The solution is to put non-safepoint debug info on many PCs, and support an approximate query which will find nearby safepoints, given an arbitrary PC. In this way the profiler's interrupt handler can find a reasonable interpretation for non-call-site PCs. Specifically, we attach debug info. (methods & bcis only) to every IR node N produced by the parser (both client and server compilers). The nmethod's debug info., which until now marks only safepoints (loop branches and call sites), is attached to the last byte of the last instruction emitted by the node N. When the profiler is presented with a random PC, it will ask the nmethod for the first debug info. at or after that PC. When the compiler transforms one node X into another Y it assign's X's recorded debug info. to Y, if Y does not already have it. However, if Y includes new sub-nodes that help it implement the semantics of X, those subnodes will not (in general) receive X's recorded debug info. This might lead to bugs; we'll have to see if it is worthwhile attempting to propagate debug info. along edges in the IR graph. Consequences of this technique: - nodes which are used to implement several BCIs (due to CSE, for example) are tagged with one of the BCIs (probably the first) - nodes are moved around in the output, and so one hot loop of machine code can potentially contribute ticks to a scattered set of BCIs - nodes which are generated outside of the parser may not have their own debug info., and so will inherit that of the next marked node in output order - a node that is radically transformed by the optimizer may turn into nodes which are lacking debug info., and so their BCIs may get credited to nodes following the transformed code in output order *** (#1 of 1): [ UNSAVED ] ###@###.###
03-12-2005
SUGGESTED FIX I asked Marty Itzkowitz: What information could the Hotspot compiler provide so that the collect/analyzer can correlate compiled code back to source lines? He wrote: We capture two callstacks, one from Java, which gives us a method ID and a byte-code-index, and the second, the native stack, which gives us a native PC. Unfortunately, the current implementation for dynamically- generated methods has -1 as the byte code index for the leaf method. The best thing for us would be to have HotSpot generate a mapping from the generated native PC to the method-id/byte-code-index. We would then use the line number tables in the class file to go from BCI to ine number. ###@###.### 10/7/04 15:23 GMT
07-10-2004