for pre-review (M): 6912064: type profiles need to be more thorough for dynamic language support
Vladimir Kozlov
Vladimir.Kozlov at Sun.COM
Tue Jan 26 15:44:05 PST 2010
John,
Good, you still did not push it.
Since I am looking on type profiling code (for bimorphic call fix)
I noticed that new code in gen_instanceof() does not check
for type check failures when the code in gen_checkcast() does:
data->as_CounterData()->count() >= 0
Was it intentional?
Thanks,
Vladimir
Vladimir Kozlov wrote:
> Looks good.
>
> Vladimir
>
> John Rose wrote:
>> OK. I updated the webrev:
>> http://cr.openjdk.java.net/~jrose/6912064/webrev.01/
>>
>> There are more comments.
>>
>> I removed the CmpU case; it is irrelevant since the parser generates
>> CmpU via a different mechanism altogether.
>>
>> I narrowed down the scope of bug 6912064 and split out the new profile
>> functionality (for non-receiver arguments) into bug 6919064.
>>
>> (The short hamming distance between bugids is an accident!)
>>
>> Igor, I have created bug 6919069 to track the update of the C1 code.
>> There are some missing bits even now, and the gap will grow as we add
>> more inputs and outputs to the profiling mechanism.
>>
>> -- John
>>
>> On Jan 14, 2010, at 11:57 AM, Vladimir Kozlov wrote:
>>
>>> John,
>>>
>>> I did not find anything alarming in these changes :)
>>> But I did not find what you did for the last two points:
>>>> - profiles need to be collected on invokedynamic instructions
>>>> - profiles should also be collected on selected non-receiver
>>>> arguments of method calls
>>> In Parse::seems_stable_comparison() there is no explanation
>>> why for ProfileDynamicTypes CmpU and CmpP always return "true".
>>> And add some comments about skipping diamond phi code.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> John Rose wrote:
>>>> In order to compile dynamically typed languages, the JVM needs to
>>>> collect more dynamic typing profile information, and use the
>>>> information it collects more completely.
>>>> Specifically:
>>>> - existing profiles on instanceof bytecodes need to be used (they
>>>> are currently ignored)
>>>> - existing profiles on invocation receivers need to be used (they
>>>> are currently used only in conjunction with inlining optimizations)
>>>> - certain type comparisons which appear monomorphic should be
>>>> compiled to fail on uncommon traps, rather than normal slow path code
>>>> - profiles need to be collected on invokedynamic instructions
>>>> - profiles should also be collected on selected non-receiver
>>>> arguments of method calls
>>>> This is a preliminary review. The current webrev addresses only the
>>>> first and third of the above points:
>>>> http://cr.openjdk.java.net/~jrose/6912064/webrev.00/
>>>> -- John
>>
More information about the hotspot-compiler-dev
mailing list