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. -- Chris > > Rémi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
