Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8058884 Reconcile deoptimizing recompilation with code splitting
  3. JDK-8060242

Compile-time expression evaluator wasn't seeing into ArrayBufferViews

XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Fixed
    • Icon: P3 P3
    • 9
    • 8u40
    • core-libs
    • b36
    • generic
    • generic

        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 after JDK-8059844 was implemented.

        Fixing this issue brought down the number of deoptimizing recompilations in mandreel from +600 to ~100.

              attila Attila Szegedi
              attila Attila Szegedi
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: