EVALUATION
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).
|
Java