JDK-7120468 : SPARC/x86: use frame::describe to enhance trace_method_handle
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs23
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-12-12
  • Updated: 2012-03-24
  • Resolved: 2012-03-24
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 7 JDK 8 Other
7u4Fixed 8Fixed hs23Fixed
Related Reports
Relates :  
Relates :  
Description
The trace_method_handle dump, activated by -XX:TraceMethodHandles, has been implemented before the frame::describe enhancements.

The implementation might benefit from calling frame::describe instead of implementing
its own dumping mechanism. This has been done for the ARM and PPC ports.

Comments
EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5dbed2f542ff
22-03-2012

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/5dbed2f542ff
26-01-2012

EVALUATION Goal of that RFE was to use the frame::describe debugging output to enhance the information printed by the "-XX:+TraceMethodHandles -XX:+Verbose" develop options and benefit from future improvements of frame::describe. This RFR does not impact the product build but may help future JSR292 development. The change in fact fixes a few minor bugs in the current version of trace_method_handle. Main changes are: - make frame::describe available in all non-product builds (else we could no longer build in "optimized" mode) - improvements of trace_method_handle for SPARC * protect FP result register, which was corrupted by traces * protect all globals (G6 corruption caused an issue) * walk up to the right frame to dump * safely build a frame on which to call describe (see below) - improvements of trace_method_handle for x86 * properly pass r13 (and not rsi) as the saved_sp on LP64 * protect FP result register, which was corrupted by traces * build a real frame in the stub wrapper to allow stack walking * walk up to the right frame to dump * safely build a frame on which to call describe (see below) Note on the "safely build a frame": trace_method_handle is called from very different call sites. For some of them (mainly ricochet and return adapters), we cannot call the existing frame constructors to build a frame. They fails for various assertions (often because the constructor expects a valid PC at some specified location). Instead of modifying the constructors or remove assertions for this debug only code, we instead switch to a simpler output instead of building a frame and calling frame::describe. The test is currently very simple (same as has_mh) and seems to work for all the test we ran. If necessary (for instance if new adapters are created), we may have to refine how "walkable" is set or change the constructors to support these special frames.
26-01-2012