[9] RFR (M): 8027827: Improve performance of catchException combinator

[John Rose]

On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Updated webrev:
> http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/
> 
> I finally figured out how to make caching work. This webrev contains these changes.
> 
> I changed LF representation a bit and added 2 auxiliary method handles - argument boxing and wrapping into Object[] and result unboxing. These operations depend on actual type and can't be shared among arbitrary combinators with the same basic type. They are used only during LF interpretation and are completely ignored in compiled LFs.

This is a good step forward, thanks!

Some comments:

I prefer the bounds check expression pos+3 < lambdaForm.names.length.  (One integer constant, limit to right.)

The predicate isGuardWithCatch must test all three subforms.  Or else there must be assertions to ensure that names[pos+2] is of the expected form.  The problem is that LF's can sometimes be edited (e.g., by binding operations) and there is no insurance that your pattern of three expressions will be preserved in all cases.

I see you are trying to do unboxing elimination here; this is not a safe or effective way to do it, IMO.  Put in a "FIXME" comment and file a bug to deal better with unboxing ops in LFs.  I have some WIP code toward this end which we can talk about.  You've probably seen of that business, about internally LF marking expressions as intrinsics to guide bytecode generation.

Why is the logic about cachedLambdaForm commented out?  It looks correct, but is there a bug?

Consider replacing GUARD_WITH_CATCH with Lazy.NF_guardWithCatch, and using the NF instead of MH for the intrinsic.

— John