Boxed types and constat propagation

[Kohsuke Kawaguchi]

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/