- 
    Bug 
- 
    Resolution: Fixed
- 
     P3 P3
- 
    repo-valhalla
                    sergey.kuksenko@oracle.com (20170617): 
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?
            
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?
- relates to
- 
                    JDK-8182863 [MVT] Enable compilation of lambda forms with value type arguments -           
- Closed
 
-