Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8010700

Revisit method specialization

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Not an Issue
    • Icon: P2 P2
    • None
    • 9
    • core-libs
    • None

      (ported from kenai to keep the info).

      Original CR info preserved (this is not exactly how we will do it - it will instead sit on top of RecompilableScriptFunctionData)

      Every toObject conversion everywhere in the code is our enemy.

      We should revisit the early prototype for method specialization

      Don't generate any explicit revert stubs anymore. Use method handle converters
      Use method Id to guard on, instead of logic in checkFunction
      Decide what to specialize and where. We can specialize functions both on their call sites and on what their parameters actually turn into in the IR. The latter is probably easier at first and provides us with one decent specialization.

      --


      another problem with call specialization is that you really have no idea what a.b[x](double, double) is at compile time
      [9/19/12 1:54:05 PM] Marcus Lagergren: we should do the toObject conversion only at the receiver if necessary, not at the callsite

      ---

      Let it be forever known here so I don't fall into this mental trap one more time:

      function square(a) {
        return a * a;
      }

      generates to:

      method(O, O)
      aload 0
      toNumber
      aload 1
      toNumber
      dmul
      dreturn

      We would be tempted to generate it as

      method(D D)
      dload 0
      dload 2
      dmul
      dreturn
      as we know nothing is done with the parameters that isn't first casting them to a double, or rather executing a toNumber function.

      One might be tempted to implement the generic version as

      method(O O)
          call square method handle (toNumber(O), toNumber(O))
      But this won't work.

      toNumber maybe ha side effects if someone passes an object with an overwritten valueOf. This can basically do anything.

      Thus param1*param1 can NEVER be anything else than toNumber(param1)*toNumber(param2).

      It's as if Brendan Eich manually removed any optimization opportunities in this language.

      We CAN specialize if we generate a double version of the method and a separate object version of the method, in effect doubling code bloat.
      This is probably not feasible in the generic case, and as there is no way to know most of callsite -> callee mappings at compile time this will be problematic.

      I still see some limited things that can be done in this space and I will document their progress here.



            lagergren Marcus Lagergren
            lagergren Marcus Lagergren
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: