United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6836054 java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException
JDK-6836054 : java/util/Arrays/CopyMethods.java fails on solaris-sparc with IllegalArgumentException

Details
Type:
Bug
Submit Date:
2009-04-30
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
solaris
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs16 (b04)

Related Reports
Backport:
Backport:

Sub Tasks

Description
java/util/Arrays/CopyMethods.java fails on solaris-sparcv9 with IllegalArgumentException
Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: [public static java.lang.Object[] java.util.Arrays.copyOf(java.lang.Object[],int), java.lang.Object@1efb836, 0] : java.lang.IllegalArgumentException: argument type mismatch
Test results: failed: 1

vmopts: "-server -Xcomp -showversion -XX:+AggressiveOpts"
doesn't fail without -Xcomp or without AggressiveOpts.

Found during 6u14p testing, but also reproduced with latest 7.

                                    

Comments
EVALUATION

This isn't a new bug, it's just that changes to InlineSmallCode made the problem show up with this test case.  I reproduced it all the way back to the putback for 6259129 which introduced scalar replacement and this just seems to be a bug with it.  Run the test case with "-server -XX:+DoEscapeAnalysis -XX:+PrintCompilation -XX:Flags=co.save -XX:InlineSmallCode=1500 CopyMethods" where co.save contains:

CompileOnly=CopyMethods.makeArray
CompileOnly=CopyMethods.fullTests
CompileOnly=java.lang.reflect.Array::newInstance 

Just grab the test case from /java/re/jdk/1.7.0/latest/ws/jdk/test/java/util/Arrays/CopyMethods.java.
                                     
2009-05-06
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/b2934faac289
                                     
2009-05-12
PUBLIC COMMENTS

Problem:
Escape Analysis requires to know the allocation actual type 
statically during compilation to pass it to debug info for 
restoring objects during deoptimization.
But reflection allocation load the allocation type dynamically 
from passed j.l.Class object. The allocation type
is set to j.l.Object assuming that caller will cast
to exact type. In the failing case there is no cast
to array type so debug info contains incorrect type
(j.l.Object) for scalar replaced array allocation.
It causes the Exception after deoptimization when
the object is restored as j.l.Object instead of array.

Solution:
Do not mark an allocation as scalar replaceable if
its actual type in unknown statically.
                                     
2009-05-12



Hardware and Software, Engineered to Work Together