-
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
-
JDK-8060725 Compile-time expression evaluator wasn't seeing into ArrayBufferViews
-
- Resolved
-
-
JDK-8064250 Compile-time expression evaluator wasn't seeing into ArrayBufferViews
-
- Resolved
-
-
JDK-8070487 Compile-time expression evaluator wasn't seeing into ArrayBufferViews
-
- Resolved
-
-
JDK-8085751 Compile-time expression evaluator wasn't seeing into ArrayBufferViews
-
- Resolved
-