Request For Review, 7120468: SPARC/x86: use frame::describe to enhance trace_method_handle

Bertrand Delsart bertrand.delsart at oracle.com
Wed Jan 25 08:42:26 PST 2012


Hi all,

Here is the third (and last) frame::describe related CR I wanted to putback:

http://cr.openjdk.java.net/~bdelsart/7120468/00/webrev/

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.

If you are curious, I attached an example (an amd64) that shows a 
ricocher sequence, including both walkable and non walkable frames.

Regards,

Bertrand
-- 
Bertrand Delsart,               bertrand.delsart at oracle.com,
Sun-Oracle France, 180 av. de l'Europe, ZIRST de Montbonnot,
38334 Saint Ismier,                                  FRANCE
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TRACE_EXAMPLE
Url: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120125/fa4cabac/TRACE_EXAMPLE.ksh 


More information about the hotspot-compiler-dev mailing list