Boxed types and constat propagation

[Christian Thalinger]

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 at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev