JDK-8130923 : C1 trouble in VarHandle.getObject tests
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-10
  • Updated: 2017-01-30
  • Resolved: 2016-05-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
It seems that in addition to JDK-8130920, getObject pays additional cost with C1:

o.o.v.get.acc.ObjectTest.plain                        avgt   15   16.382 �� 0.009  ns/op
o.o.v.get.acc.ObjectTest.unsafe                       avgt   15   18.902 �� 0.009  ns/op
o.o.v.get.acc.ObjectTest.varHandle                    avgt   15  104.206 �� 5.003  ns/op

The disassembly shows additional Class.cast dance:
After JDK-8131682 and JDK-8131782 fixed, the only minor remaining issue is JDK-8135033, which can be handled separately. Closing this one as fixed.

The actual problem is mishandling of Class.cast by C1 (JDK-8131782), and should be fixed in C1.

One of the things that becomes apparent when messing with more optimal code for C1, is that once you move enough code (but still get no inlining), the alignment for call targets gets into the way. This is tracked as JDK-8131682, and seems optimizeable.