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. >> But I think I got the answer to half of my questions anyway --- that I >> wasn't failing to have HotSpot optimize to its fullest potential, and >> instead it's the design choice / current shortcoming in HotSpot that >> it doesn't consider "Boolean.FALSE.value" as "false". >> >> That leaves me just with the other question, that how other >> implementors are coping with this. The observation from Mark was >> interesting --- maybe it actually doesn't cost as much as it looks in >> the assembly, with branch prediction and Boolean.FALSE on cache, etc. >> OTOH, I still think the constant propagation can trigger more >> optimizations and those add up to something non-trivial... >> > > and there is another problem which is that currently the escape analysis > doesn't propagate information through an invokedynamic > (it consider target.invokeExact as a native call). > > and yes, the current state, final fieds are constants, getClass() == A.class > is not recognized as a kind of instanceof, invokedynamic doesn't play > well with > escape analysis should be fixed. I didn't know about others, that's good to know. -- Kohsuke Kawaguchi http://kohsuke.org/ _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
