JDK-7058510 : multinewarray with 6 dimensions uncommon traps in server compiler
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-23
  • Updated: 2013-01-23
  • Resolved: 2011-09-30
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 7 JDK 8 Other
7u2 b04Fixed 8Fixed hs22Fixed
Related Reports
Relates :  
Description
I noticed this code

	http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/5bb91b0db2c9/src/share/vm/opto/parse3.cpp
	410 void Parse::do_multianewarray() {
	411   int ndimensions = iter().get_dimensions();
	412 
	413   // the m-dimensional array
	414   bool will_link;
	415   ciArrayKlass* array_klass = iter().get_klass(will_link)->as_array_klass();
	416   assert(will_link, "multianewarray: typeflow responsibility");
	417 
	418   // Note:  Array classes are always initialized; no is_initialized check.
	419 
	420   enum { MAX_DIMENSION = 5 };
	421   if (ndimensions > MAX_DIMENSION || ndimensions <= 0) {
  !!	422     uncommon_trap(Deoptimization::Reason_unhandled,
	423                   Deoptimization::Action_none);
	424     return;
	425   }
	....
	507 }

and tried writing a test program that used an array with 6 dimensions and compared it to the same test using an array with 5 dimensions.  The results were surprising.  First the test with an array of 5 dimensions

        $ $Deployed/solaris-i586/JDK-7_b145/bin/javac MultiNewArray5.java
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -Xint MultiNewArray5
        That took 6.010 seconds.
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -client MultiNewArray5
        That took 3.048 seconds.
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -server MultiNewArray5
        That took 0.124 seconds.

So far so good.  But when I try an array with 6 dimensions

        $ $Deployed/solaris-i586/JDK-7_b145/bin/javac MultiNewArray6.java
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -Xint MultiNewArray6
        That took 6.645 seconds.
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -client MultiNewArray6
        That took 3.537 seconds.
        $ $Deployed/solaris-i586/JDK-7_b145/bin/java -server MultiNewArray6
        That took 63.718 seconds.

The uncommon trap causes the server code to run 10x slower than the interpreter, and 18x slower than the interpreter.  Wouldn't it be better to bail out of the compilation and mark the method as uncompilable so that it runs in the interpreter (or with the tier 1 client compilation)?

I've attached the MultiNewArray6.java (derived from a random number generator I was testing).  The change to MultiNewArray5.java is to delete one dimension of the array, and change the name of the classes from *6 to *5.

Comments
EVALUATION See main CR
30-08-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/263247c478c5
17-07-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-main/hotspot/rev/263247c478c5
13-07-2011

EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/263247c478c5
09-07-2011