-
Sub-task
-
Resolution: Fixed
-
P3
-
8u40
-
b36
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8085751 | emb-9 | Attila Szegedi | P3 | Resolved | Fixed | team |
| JDK-8064250 | 8u45 | Attila Szegedi | P3 | Resolved | Fixed | b01 |
| JDK-8060725 | 8u40 | Attila Szegedi | P3 | Resolved | Fixed | b12 |
| JDK-8070487 | emb-8u47 | Attila Szegedi | P3 | Resolved | Fixed | team |
Our compile-time type evaluator can currently determine that an expression "a[i]" will need to be deoptimized at least to double if it has a NumberArrayData underlying it. However, this only worked for ordinary JavaScript arrays.
We also support the array buffer view API, and lot of octane tests (pdfjs, gbemu, and mandreel) depend on it. However, type evaluator didn't have insight into its underlying types, thus code that uses them heavily didn't get bulk-deoptimized.
This was particularly pronounced once large portions of mandreel became subject to optimistic typing afterJDK-8059844 was implemented.
Fixing this issue brought down the number of deoptimizing recompilations in mandreel from +600 to ~100.
We also support the array buffer view API, and lot of octane tests (pdfjs, gbemu, and mandreel) depend on it. However, type evaluator didn't have insight into its underlying types, thus code that uses them heavily didn't get bulk-deoptimized.
This was particularly pronounced once large portions of mandreel became subject to optimistic typing after
Fixing this issue brought down the number of deoptimizing recompilations in mandreel from +600 to ~100.
- backported by
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-