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

    Details

    • Type: Sub-task
    • Status: Resolved
    • Priority: P3
    • Resolution: Fixed
    • Affects Version/s: 8u40
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b36
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        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.

          Attachments

            Issue Links

              Activity

                People

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

                  Dates

                  Created:
                  Updated:
                  Resolved: