hg: mlvm/mlvm/jdk: meth: performance work

[Christian Thalinger]

On Jul 14, 2012, at 6:02 PM, john.r.rose at oracle.com wrote:

> Changeset: 56879e348afe
> Author:    jrose
> Date:      2012-07-14 18:02 -0700
> URL:       http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/56879e348afe
> 
> meth: performance work
> 
> + meth-lazy-7023639.bmh.patch
> + meth-lazy-7023639.init.patch

Somehow this patch prevents compilation(?) of LFs and we always run in the LF interpreter:

                            @ 20   java.lang.invoke.LambdaForm$MH007/1350355205::linkToCallSite (18 bytes)   inline (hot)
                              @ 1   java.lang.invoke.Invokers::getCallSiteTarget (8 bytes)   inline (hot)
                                @ 4   java.lang.invoke.MutableCallSite::getTarget (5 bytes)   inline (hot)
                              @ 14   java.lang.invoke.LambdaForm$LFI005/1770098351::interpret_L (29 bytes)   inline (hot)
                                @ 25   java.lang.invoke.LambdaForm::interpretWithArguments (124 bytes)   inline (hot)
               !                  @ 41   java.lang.invoke.LambdaForm::compileToBytecode (95 bytes)   too big
                                  @ 53   java.lang.invoke.LambdaForm::arityCheck (130 bytes)   inline (hot)
                                    @ 113   java.lang.invoke.MethodHandle::internalForm (5 bytes)   inline (hot)
                                  @ 73   java.util.Arrays::copyOf (13 bytes)   inline (hot)
                                    @ 3   java.lang.Object::getClass (0 bytes)   (intrinsic)
                                    @ 6   java.util.Arrays::copyOf (47 bytes)   (intrinsic)
                                  @ 96   java.lang.invoke.LambdaForm::interpretName (122 bytes)   already compiled into a big method

Haven't figured out what the exact problem is.

-- Chris

> ! series
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev