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

[Tom Rodriguez]

Looks good.

tom

On Jan 25, 2012, at 8:42 AM, Bertrand Delsart wrote:

> 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
> <TRACE_EXAMPLE.txt>