Any chance you can share that patch with us? It'd give me some pointers into poking around JDK code, now that I learned how to build it...
On 04/23/2012 04: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. > > Rémi > > -- Kohsuke Kawaguchi http://kohsuke.org/ _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
