Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
P3
-
Resolution: Fixed
-
Affects Version/s: repo-valhalla
-
Fix Version/s: repo-valhalla
-
Component/s: hotspot
-
Labels:
-
Subcomponent:
Description
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?
Attachments
Issue Links
- relates to
-
JDK-8182863 [MVT] Enable compilation of lambda forms with value type arguments
-
- Closed
-