for pre-review (M): 6912064: type profiles need to be more thorough for dynamic language support

[Vladimir Kozlov]

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
>