Uploaded image for project: 'Harmony'
  1. Harmony
  2. HARMONY-6065

[drlvm][testing] VMTT generates bad lookupswitch code 25% of the time

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5.0M8
    • Fix Version/s: 5.0M9
    • Component/s: DRLVM
    • Labels:
      None

      Description

      The VMTT tool appears to generate bad bytecode when the lookupswitch instruction starts at instruction (4n-1). According to the spec, this code:

      0: nop
      1: nop
      2: iload_1
      3: lookupswitch

      { 1: 44 4: 47 9: 51 16: 53 default: 57 }

      should generate this output:
      // 0: nop
      x00
      // 1: nop
      x00
      // 2: iload_1
      x1B
      /* lookupswitch size is:
      1: lookupswitch
      0: padding
      4: default address
      4: npairs
      4: case 1 match (1)
      4: case 1 value
      4: case 2 match (4)
      4: case 2 value
      4: case 3 match (9)
      4: case 3 value
      4: case 4 match (16)
      4: case 4 value
      Total: 41
      */
      // 3: lookupswitch

      { // 1: 44 // 4: 47 // 9: 51 // 16: 53 // default: 57 // }

      xAB // lookupswitch
      // no padding
      x00 x00 x00 x36 // default: 3+54=57
      x00 x00 x00 x04 // npairs: 4
      x00 x00 x00 x01 // match: 1
      x00 x00 x00 x29 // offset 3+41=44
      x00 x00 x00 x04 // match: 4
      x00 x00 x00 x2C // offset 3+44=47
      x00 x00 x00 x09 // match: 9
      x00 x00 x00 x30 // offset 3+48=51
      x00 x00 x00 x10 // match: 16
      x00 x00 x00 x32 // offset 3+50=53

      Instead, it generates this output:
      // 0: nop
      x00
      // 1: nop
      x00
      // 2: iload_1
      x1B
      /* lookupswitch size is:
      1: lookupswitch
      4: padding - looks like VMTT is giving us 4 bytes?!?
      4: default address
      4: npairs
      4: case 1 match (1)
      4: case 1 value
      4: case 2 match (4)
      4: case 2 value
      4: case 3 match (9)
      4: case 3 value
      4: case 4 match (16)
      4: case 4 value
      Total: 41
      */
      // 3: lookupswitch

      { // 1: 44 // 4: 47 // 9: 51 // 16: 53 // default: 57 // }

      xAB // lookupswitch
      x00 x00 x00 x00 // 4 bytes of padding?
      x00 x00 x00 x36 // default: 3+54=57
      x00 x00 x00 x04 // npairs: 4
      x00 x00 x00 x01 // match: 1
      x00 x00 x00 x29 // offset 3+41=44
      x00 x00 x00 x04 // match: 4
      x00 x00 x00 x2C // offset 3+44=47
      x00 x00 x00 x09 // match: 9
      x00 x00 x00 x30 // offset 3+48=51
      x00 x00 x00 x10 // match: 16
      x00 x00 x00 x32 // offset 3+50=53

      In other words, it's emitting 4 bytes of padding instead of 0 bytes of padding after the xAB lookupswitch instruction. This is 4-aligned, but not what most VMs expect.

        Attachments

        1. 6065-switchpadding.diff
          1 kB
          Andrew Cornwall

          Activity

            People

            • Assignee:
              leshik Alexei Fedotov
              Reporter:
              andrewc Andrew Cornwall
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: