Bug ID: JDK-8130923 C1 trouble in VarHandle.getObject tests

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

Versions (Unresolved/Resolved/Fixed)

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.

JDK 9
9Fixed

Related Reports

Blocks :	JDK-8131782 - C1 Class.cast optimization breaks when Class is loaded from static final
Relates :	JDK-8131682 - C1 should use multibyte nops everywhere
Relates :	JDK-8135033 - C1 should fast-path Object.class.isInstance(obj) to null check
Relates :	JDK-8130920 - C1 trouble in VarHandle.get tests
Relates :	JDK-8131782 - C1 Class.cast optimization breaks when Class is loaded from static final

Description

It seems that in addition to JDK-8130920, getObject pays additional cost with C1:
http://cr.openjdk.java.net/~shade/8130923/ObjectTest.java

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:
 http://cr.openjdk.java.net/~shade/8130923/c1.perfasm
 http://cr.openjdk.java.net/~shade/8130923/c2.perfasm

Comments

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.

19-05-2016

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

17-07-2015

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.

17-07-2015