-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b05
-
generic
-
generic
-
Verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-2196668 | 7 | John Rose | P3 | Closed | Fixed | b104 |
| JDK-2197815 | 6u23 | John Rose | P3 | Resolved | Fixed | b01 |
| JDK-2199714 | 6u22m | John Rose | P3 | Resolved | Fixed | b01 |
| JDK-2197525 | 6u21p | John Rose | P3 | Resolved | Fixed | b03 |
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.
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.
- backported by
-
JDK-2197525 invokedynamic call sites deoptimize instead of executing
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- relates to
-
-
- Closed
-