Boxed types and constat propagation

[Rémi Forax]

On 04/25/2012 06:38 PM, Christian Thalinger wrote:
> 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.

I've done something similar in the backport, it takes an array
(in fact a map object to integer index but that an implementation detail)
and generates a class with one static final field by array item
and I substitute the bound argument array access by the static field
when generating the bytecode.

My main issue is that when the MethoHandle is GCed,
the bound arguments are not GCed.

>
> -- Chris

Rémi