review request (M): 7111138: delete the obsolete flag -XX:+UseRicochetFrames

[Christian Thalinger]

On Jan 19, 2012, at 1:00 AM, John Rose wrote:

> http://cr.openjdk.java.net/~jrose/7111138/webrev.00/
> 
> This changeset acknowledges that the UseRicochetFrame flag can only be set to true, and that workaround code in the JVM for a pre-ricochet-frame transitional period is no longer needed.  Likewise, code included under the macro "TARGET_ARCH_NYI_6939861" is removed, since that code was used only during the transitional period.

Looks good.  -- Chris

> 
> -- John
> 
> Background:
> 
> Ricochet frames were introduced for x86 in this changeset:
>  http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/167b70ff3abc
> 
> Further changesets introduced ricochet frame support for sparc, ppc, and arm.
> 
> During the transitional period between the ports, a platform-specific diagnostic flag UseRicochetFrames was introduced which would allow porters to turn on and off the use of these frames.  This flag also as internally set to true or false depending on port status.  Since the JDK code which supports non-ricochet-based method handles has been retired, the "false" setting of the flag no longer makes sense, so we are removing the flag altogether.
> 
> Likewise, the macro TARGET_ARCH_NYI_6939861 was defined (to "1") for ports that did not yet have assembly code for supporting UseRicochetFrames.  At this point, since all ports do have such assembly code, code under that macro is obsolete and can be deleted.
> 
> Technically, ricochet frames support signature polymorphism for recursive method handles.
> 
> A recursive method handle is one which can execute two or more targets, one after the other.  The final target can be tail-called, but the other targets must be called with some sort of stack frame or continuation to direct execution to the next target.  This is what a ricochet frame does.  Note that the return value of a non-final target must be made available, at least optionally, to the subsequent target(s).  Also, incoming arguments must be made available, at least optionally, to one or more of the targets.  Cf. MethodHandles.foldArguments for a more complex example.
> 
> A single instance of ricochet frame assembly code can handle a broad range of input argument signatures.  In fact, there are a finite number of ricochet frame assembly stubs, which collectively handle all possible argument type combinations.
> 
> The previous version of method handles had a finite (but uncomfortably large) number of Java-coded handler routines, each suited to a relatively small number of argument type combinations.  This previous version did not handle all arities and argument type combinations, and so was discarded shortly after the four main CPU ports were completed.
> 
> Note that a future set of changes is likely to eliminate ricochet frames also, in favor of a solution which uses a new intermediate representation for recursive method handles, the "lambda form".  This representation will compile to bytecodes, or else (optionally) be more directly processed by a JVM implementation.  For a preview, see the Da Vinci Machine patch repository, especially:
>  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy.txt
>  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/meth-lazy-7023639.patch
>  http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-lazy-7023639.patch
> 
> The purpose of this later change will be to reduce the volume of assembly code and make MH invocations easier to analyze by the JIT.