MH compilation is broken in valhalla(mvt branch) build

[Tobias Hartmann]

Thanks Sergey, I'll have a look as soon as I'm freed up with from work.

On 19.06.2017 10:05, David Simms wrote:
> Thanks for reporting this Sergey, I filed a "mvt" labelled bug for tracking:
> 
> https://bugs.openjdk.java.net/browse/JDK-8182453

For compiler triaging we need to set a fix version. Any updates on the mvt affects/fix version? Or should we just use 10 for now?

Thanks,
Tobias

> On 17/06/17 01:13, Sergey Kuksenko wrote:
>> I found that in valhalla build (mvt branch) MH compilation is broken if MH is stored in non-final field. Cost of MH invocation is increased ~100x times.
>>
>> Benchmark sources and compiled jar file could be found:
>> http://cr.openjdk.java.net/~skuksenko/valhalla/mh_issue/
>>
>> Results:
>> * on Java9 & Java8
>>
>> Benchmark            Mode  Cnt  Score   Error  Units
>> XMH.walkFinal        avgt    5  4.500 ± 0.276  ns/op
>> XMH.walkNonFinal  avgt    5  4.856 ± 0.011  ns/op
>>
>> * on MVT
>> Benchmark            Mode  Cnt    Score    Error  Units
>> XMH.walkFinal        avgt    5    4.406 ±  0.016  ns/op
>> XMH.walkNonFinal  avgt    5  457.484 ± 10.550  ns/op
>>
>> These benchmarks are Java8 compatible and doesn't contain any Q-types.
>>
>> Besides, Vladimir told me that:
>>
>> > I briefly looked into the benchmarks and it seems the difference is caused by a compiler bug: there are no compilations happening for stand-alone lambda forms with Q-types.
>> > So, when inlining doesn't happen, the Q-typed LF code stays interpreted forever.
>>
>> Maybe that issues are related. Also I'd like to ask is infinite interpreting of Q-types LF code known behavior? If yes, are there any estimations when Q-types LF will be compiled?
> 
>