Boxed types and constat propagation
christian.thalinger at oracle.com
Wed Apr 25 09:38:26 PDT 2012
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
> 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.
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
More information about the mlvm-dev