[13] RFR: 8227223: [Graal] Implement basic type consistency checks for Low level MH intrinsics

[Vladimir Kozlov]

Good ;)

Thank you.

Vladimir

On 7/4/19 11:12 AM, Jamsheed wrote:
> slight oversight, thought webrev provided Vladimir Kozlov was based on jdk14 and it cleanly applied on jdk13. it was 
> indeed jdk13 based. removed duplicates.
> 
> On 04/07/19 9:09 PM, Jamsheed wrote:
>> Request for review for the backport of JDK-8221577 [1] .
>>
>> The fix [2] was integrated into JDK 14 as part of JDK-8225497:"Update Graal" [1].
>>
>> jdk13 backport webrev: https://cr.openjdk.java.net/~kvn/8221577/webrev.00/ (Thank you, Vladimir Kozlov)
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8227223
>>
>> Description of problem by Vladimir Ivanov:
>>
>> "Method handle linkers (MethodHandle.linkTo*) are inherently unsafe: it's possible to use arbitrary signature to 
>> invoke a method and behavior is implementation/platform-specific when argument type mismatch occurs (e.g., int vs 
>> float). Type checking for method handle invocation happens earlier: either in MethodHandle.invoke/invokeExact() or as 
>> part of invokedynamic linkage. MH linkers implement low-level semantics of different invocation modes.
>>
>> Though such type mismatches (int vs float) shouldn't occur at runtime (it's guaranteed by how method handles are 
>> constructed), JIT-compiler can observe it on unreachable branches which can't be proved as such at compile-time. (See 
>> JDK-8166110 for an example.)
>>
>> In order to avoid paradoxes in IR, C2 doesn't inline through MH.linkTo* methods if there's type mismatch for any 
>> argument or return type (decision is made in ciMethod::is_consistent_info())."
>>
>> Best Regards,
>>
>> Jamsheed
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8221577
>>
>> [2] https://github.com/oracle/graal/commit/d880341edf09d6a14021e2c7f09f70eda56c1c9d
>>