JDK-6969574 : invokedynamic call sites deoptimize instead of executing
- Type: Bug
- Component: hotspot
- Sub-Component: compiler
- Affected Version: 7
- Priority: P3
- Status: Closed
- Resolution: Fixed
- OS: generic
- CPU: generic
- Submitted: 2010-07-15
- Updated: 2013-04-15
- Resolved: 2011-03-08
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.
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 | JDK 7 | Other |
|---|---|---|
| 6u21pFixed | 7Fixed  |
hs19Fixed |
Related Reports
|
Relates :
|
Description
Due to a bug in ciTypeFlow, invokedynamic call sites deoptimize unexpectedly. The problem was observed by a customer: http://mail.openjdk.java.net/pipermail/mlvm-dev/2010-June/001767.html Eric Bodden bodden at st.informatik.tu-darmstadt.de Fri Jun 4 01:43:19 PDT 2010 I did some simple micro-benchmarking with the current implementation of invokedynamic. In the attached test class, I call a method "greeter" 100,000,000 times using invokedynamic and then using reflection. Reflection only takes about 1338ms, while invokedynamic takes about 12099. (This was taken on OSX 10.6, with build "1.7.0-internal-stephen_2010_05_28_19_48-b00"). By the way invokedynamic works, I had expected it to be at least as fast as a reflective call.
Comments
|