You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Andrew Cornwall (JIRA)" <ji...@apache.org> on 2009/03/02 19:04:56 UTC
[jira] Closed: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Cornwall closed HARMONY-6065.
------------------------------------
That's a very pretty fix!
Issue verified. Thanks.
> [drlvm][testing] VMTT generates bad lookupswitch code 25% of the time
> ---------------------------------------------------------------------
>
> Key: HARMONY-6065
> URL: https://issues.apache.org/jira/browse/HARMONY-6065
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Affects Versions: 5.0M8
> Reporter: Andrew Cornwall
> Assignee: Alexei Fedotov
> Fix For: 5.0M9
>
> Attachments: 6065-switchpadding.diff
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.