Lazy Method Handle update

[Jeroen Frijters]

Thanks for the update. This sounds great. It looks like this would be helpful for me as well. Is the LambdaForm stuff written in Java?

Hopefully my strategy of doing nothing will pay off ;-)

Regards,
Jeroen

> -----Original Message-----
> From: mlvm-dev-bounces at openjdk.java.net [mailto:mlvm-dev-
> bounces at openjdk.java.net] On Behalf Of John Rose
> Sent: Wednesday, May 09, 2012 21:35
> To: Da Vinci Machine Project
> Subject: Lazy Method Handle update
> 
> Lazy Method Handles is a project to defer code generation for method
> handle behavior, and minimize requirements for support from hand-written
> assembly code.
> 
> The idea is to make all method handle behavior visible to the JVM
> compiler, so that it can be optimized properly.  Assembly code cannot be
> optimized.
> 
> In JDK 7 FCS a method handle is represented as a chain of argument
> transformation blocks, ending in a pointer to a methodOop.  The argument
> transformations are assembly coded and work in the interpreter stack.
> The reason this is not outrageously slow is that we vigorously inline
> method handle calls whenever we can.  But there is a performance cliff
> you can drop off of, when you are working with non-constant MHs.  (BTW,
> invokedynamic almost always inlines its target.)  Project Lambda needs
> us not to drop off of this cliff.
> 
> To fix this, we are now representing the argument transformations using
> a simple AST-like IR, called a LambdaForm.  This form can be easily
> rendered down to bytecodes.  (Eventually it maybe directly rendered to
> native code.)  The form is *also* interpretable by a Java-coded AST
> walker.  This allows the system to be lazy, and to work hardest on
> optimizing those method handles that are actually called frequently.
> The laziness also helps simplify bootstrapping.  The remaining assembly
> code is much smaller, and can be mirrored in the JIT IR and optimized.
> 
> Here's an update on where we are.  Christian Thalinger, Michel Haupt,
> and I are currently working on the following tasks:
> 
> A. clean out the compiled method calling path, for non-constant method
> handles B. flatten the BMH layout (no boxing, linked lists, or arrays)
> C. make the handling of MethodType checking visible to the compiler
> (removing more assembly code) D. tuning reuse and compilation of
> LambdaForm instances E. profiling MH.LambdaForm values at MH call sites
> F. tuning optimization of call sites involving LFs
> 
> For A. the remaining snag is getting the argument register assignments
> correct for the call to the target method.  There is also an issue with
> representing non-nominal calls in the backend.
> 
> For B. we are currently working on bootstrap issues.  The idea here is
> that, while we can do escape analysis, etc., a cleaner data structure
> will make the compiler succeed more often.
> 
> For C. we have a refactoring in process for moving the MT value out of
> the methodOop.
> 
> Chris, Michael, and I are working on A, B, C, respectively.  We think a
> first cut of lazy MHs needs the first three items in order to be
> reasonably faster than the all-assembly implementation of JDK 7.
> 
> In order to address the infamous NoClassDefFound error, we are
> minimizing nominal information in MH adapter code (LambdaForms and their
> bytecode).  Only names on the BCP will be in adapter code.   Part C. is
> an important part of this, since it allows the system to internally
> "flatten" calls like MH.invokeExact((MyFunnyType)x) to
> MH.invokeExact((Object)x).  The new internal MH methods (invokeBasic,
> invokeStatic, etc.) all use "denominalized" types, which is to say that
> all reference types are represented as java.lang.Object.
> 
> Best wishes,
> - John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev