On 04/25/2012 06:38 PM, Christian Thalinger wrote: > On Apr 23, 2012, at 4:29 PM, Rémi Forax wrote: > >> On 04/24/2012 12:57 AM, Kohsuke Kawaguchi wrote: >>> On 04/23/2012 11:18 AM, Rémi Forax wrote: >>>>> So again, I don't see how shifting from method handle tree to byte >>>>> code generation would somehow make this non-issue. >>>> In fact, it's easy to know that a.foo() is a boolean because >>>> && can be only applied on booleans so the invokedynamic call >>>> corresponding to a.foo() should return a boolean. >>>> From the compiler perspective, you have to back-propagate >>>> the excepted type from the root to the leaf. >>> Charles was alluding to the same thing, so I was thinking about this, >>> and I think I understand it now. >>> >>> That's a lot of optimization that I otherwise wouldn't have to do, if >>> only boxed types and constant propagation worked well, but yeah, I see >>> how it can work now. >>> >>> Thanks for all the insights. >> BTW, I've patched the JIT to consider all final fields of a class of >> java/lang as truly final >> but that not enough for having the escape analysis to work with integers. >> It seems that because of the cache used in Integer.valueOf(), the JIT >> considers >> that the Integers are not escapable. > Correct. That's the main problem. Unfortunately the caching is now part of > the spec. > > Although something that John and I talked about yesterday could help here: > immutable (or stable) arrays. We might add some optimization for this soon > since we'd need it for bound arguments in our new JSR 292 implementation.
I've done something similar in the backport, it takes an array (in fact a map object to integer index but that an implementation detail) and generates a class with one static final field by array item and I substitute the bound argument array access by the static field when generating the bytecode. My main issue is that when the MethoHandle is GCed, the bound arguments are not GCed. > > -- Chris Rémi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
