Can't inline a monomorphic call site when using default (package) visibility.

Reported on forum thread:
    http://forums.java.net/jive/thread.jspa?threadID=13130&tstart=0

The call to B.getx() is not inlined using 6.0 but is inlined using 5.0.
class A {
  int x;
  int getx() { return x; }
}
class B extends A {
  int y;
}

The call to "protected" E.getx() is inlined using both 6.0 and 5.0.
class D {
  int x;
  protected int getx() { return x; }
}
class E extends D {
  int y;
}

> /export/jdk/5.0/jdk1.5.0_06/bin/java_g -XX:CompileOnly=Kiwi.runfast -XX:CompileOnly=Kiwi.runslow -XX:+PrintCompilation -XX:+PrintInlining Kiwi
VM option 'CompileOnly=Kiwi.runfast'
VM option 'CompileOnly=Kiwi.runslow'
VM option '+PrintCompilation'
VM option '+PrintInlining'
  1%      Kiwi::runslow @ 4 (24 bytes)
      @ 11   A::getx  inline (hot)
  2%      Kiwi::runfast @ 4 (24 bytes)
      @ 11   D::getx  inline (hot)
Warmup done. Runninng...
B.getx 85ms
E.getx 84ms

> /export/jdk/6.0/jdk1.6.0/fastdebug/bin/java -XX:CompileOnly=Kiwi.runfast -XX:CompileOnly=Kiwi.runslow -XX:+PrintCompilation -XX:+PrintInlining Kiwi
VM option 'CompileOnly=Kiwi.runfast'
VM option 'CompileOnly=Kiwi.runslow'
VM option '+PrintCompilation'
VM option '+PrintInlining'
  1%      Kiwi::runslow @ 4 (24 bytes)
  1       Kiwi::runslow (24 bytes)
  2%      Kiwi::runfast @ 4 (24 bytes)
      @ 11   D::getx  inline (hot)
  2       Kiwi::runfast (24 bytes)
      @ 11   D::getx  inline (hot)
Warmup done. Runninng...
B.getx 5289ms
E.getx 99ms
Posted Date : 2006-02-17 15:33:14.0

N/A

Suspect lines:
ciMethod.cpp  452-460
  if (actual_recv != root_m->holder() &&
      !root_m->is_public() &&
      !root_m->is_protected()) {  <-----
    return NULL;
  }
Posted Date : 2006-02-17 16:05:36.0

Class hierarchy analysis used to punt on package-private methods because their rules for overriding are complex.  The fix is to carefully allow CHA with them, treating package-private methods as *possible* overrides, but never claiming that a unique package-private method is the *correct* method.  Thus, a P-P method can *disable* the CHA optimization, but only a public or protected method can be returned from the CHA walk performed by class Dependencies.  From ciMethod::find_monomorphic_target, the only time when a P-P method can be returned is when (a) that method is returned by resolve_invoke (and is therefore trustworthy) and (b) no other method is apparent below that method in the CHA context.  Constraint (b) is evaluated without regard to actual overloading relationships; any method of the same name and type is sufficient to cause CHA to (conservatively) fail.  For simple benchmarks like the customer's, this poses no restriction, and the inlining is performed correctly.  During testing, we found one case where constraint (b) spoils a valid inlining.  The call site is in GregorianCalendar.computeTime, to TimeZone.getOffsets, as follows:

	    if (zone instanceof ZoneInfo) {
		((ZoneInfo)zone).getOffsetsByWall(millis, zoneOffsets);
	    } else {
		int gmtOffset = isFieldSet(fieldMask, ZONE_OFFSET) ?
				    internalGet(ZONE_OFFSET) : zone.getRawOffset();
		zone.getOffsets(millis - gmtOffset, zoneOffsets);
	    }

Even in the 'else' branch, the compiler has proven that zone is either null or a ZoneInfo (since ZoneInfo is the only concrete implementation of TimeZone).  Thus, TimeZone.getOffsets looks (to CHA) as if it is overridden by ZoneInfo.getOffsets, but the latter is package-private (in sun.util.calendar), so the override doesn't really exist (as viewed from java.util).
Posted Date : 2006-03-22 02:01:38.0