JDK-6516101 : checkcast operations should be profiled to improve code which uses generics
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-01-22
  • Updated: 2013-11-01
  • Resolved: 2007-02-17
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 Availabitlity Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
Description
Generic types in the Java language are represented by their bounds in the JVM, and mismatches are made up by dynamic casts.  These casts are invisible to the programmer but frequent in the bytecodes.  We need better optimization of these casts in order to get top performance from generic Java code.

We can do much better if we treat casts like call sites, when profiling and optimizing.  If we profile receiver types at casts, we will be able to hoist profiled type information up to the place where a new value is pulled from a generic List or Set, which is typically much earlier than a call site that uses the new value.  If the profile is monomorphic (which is a typical case, especially in hot code), then all subsequent type checks will fold away, and all calls will be devirtualized.  We have benchmarks where this happens in hot code.

Comments
SUGGESTED FIX http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070206090659.jrose.dolphin-optimizer/workspace/webrevs/webrev-2007.02.06/index.html
2007-02-15

EVALUATION yes, done *** (#1 of 1): [ UNSAVED ] ###@###.###
2007-02-15