On 04/24/2012 01:43 AM, Kohsuke Kawaguchi wrote:
>
> Any chance you can share that patch with us? It'd give me some
> pointers into poking around JDK code, now that I learned how to build
> it...
Sure, it's easy, in ciField.cpp, there is a method named
trust_final_non_static_fields(),
you can add
if (holder->is_in_package("java/lang"))
return true;
or change the flag TrustFinalNonStaticFields to true if you have build
the fastdebug VM.
cheers,
Rémi
>
> On 04/23/2012 04: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.
>>
>> Rémi
>>
>>
>
>
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
