JDK-6211497 : CHA::analyze_call() misses some monomorphic cases
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2004-12-21
  • Updated: 2010-04-03
  • Resolved: 2005-01-12
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 6
6 b19Fixed
Description
The test came from _the mtrt specjvm98 test where I found this case
when we not inlining monomorphic call.
Note: the test should be compiled with 1.3.1 javac.

Ouput with additional CHA prints (I added):

C:\share>c:/jdk1.5.0_01/bin/java_g -server -XX:+PrintCompilation -XX:+PrintInlining test3
VM option '+PrintCompilation'
VM option '+PrintInlining'
  1       B::getXp1 (7 bytes)
CHA: 2 targets, 3 receivers
0: A::getX (0x143d5698)
1: A::getX (0x143d5698)
          'virtual call' -> @ 1   A::getX (10000 counts) (10000 rc) (5 bytes)
  2       C::check (24 bytes)
      @ 9   B::getXp1  inline (hot)
CHA: monomorphic  A::getX
        @ 1   A::getX  inline (hot)

abstract class A {
  int X;
  public int getX() { return X; }
}

abstract class B extends A {
  public int getXp1() { return getX() + 1; }
}

class C extends B {
  void B() { X = 3; }
  int check(int N) {
    int j = 0;
    for (int i=0; i<N; i++)
      j += super.getXp1();
    return j;
  }
}

public class test3 extends B {
  public static void main(String[] args) {
    C c = new C();
    int ic1 = c.check(10000);     // warmup
    int ic2 = c.check(10000);     // compile
  }
}


###@###.### 2004-12-21 23:13:57 GMT

Comments
EVALUATION The problem in the using of GrowableArray in CHA::analyze_call() to store methods and receivers handles. We use GrowableArray::contains() method to avoid duplicated entries. But should compare oops since the same oop could have different handles. This is what happens in our case. ###@###.### 2004-12-21 23:13:57 GMT
21-12-2004

SUGGESTED FIX Make GrowableArray as full template (not wrapper), specify the storage array as "E* _data;", call default constructors/destructors for each element. It will simplify Handle class and correct class GrowableArray<Handle>. We also don't need specialization GrowableArray<uint64_t>. Also add debug output of CHA::analyze_call() results. I didn't see performance difference in refWorkload. But the size of jvm.so and jvm.dll increased by 0.5% due to inlining GrowableArray's methods. Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2005/20050106115654.kvn.6211497/workspace/webrevs/webrev-2005.01.06/index.html ###@###.### 2005-1-07 16:32:49 GMT
21-12-2004