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/01/06 21:59:44 UTC
[jira] Created: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
[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
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.
[jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates
bad lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661320#action_12661320 ]
Andrew Cornwall commented on HARMONY-6065:
------------------------------------------
The second lookupswitch size above should read Total: 45. The fact that it's 45 bytes long and not 41 bytes long is the defect.
> [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
>
> 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.
[jira] Resolved: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Alexei Fedotov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexei Fedotov resolved HARMONY-6065.
-------------------------------------
Resolution: Fixed
Fix Version/s: 5.0M9
Committed at revision 748733. I have an excuse for committing this during freeze: VMTT is not a part of the release.
> [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.
[jira] Closed: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates
bad lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661319#action_12661319 ]
Andrew Cornwall commented on HARMONY-6065:
------------------------------------------
The second lookupswitch should read Total: 45 above. The fact that it's 45 bytes long and not 41 bytes long is the defect.
> [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
>
> 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.
[jira] Updated: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Cornwall updated HARMONY-6065:
-------------------------------------
Attachment: 6065-switchpadding.diff
The attached file 6065-switchpadding.diff fixes the defect.
> [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
> 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.
[jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates
bad lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661317#action_12661317 ]
Andrew Cornwall commented on HARMONY-6065:
------------------------------------------
(the second size should be 45 bytes, not 41 bytes...)
> [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
>
> 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.
[jira] Assigned: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Alexei Fedotov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexei Fedotov reassigned HARMONY-6065:
---------------------------------------
Assignee: Alexei Fedotov
> [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
> 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.
[jira] Updated: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Cornwall updated HARMONY-6065:
-------------------------------------
Comment: was deleted
> [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
>
> 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.
[jira] Updated: (HARMONY-6065) [drlvm][testing] VMTT generates bad
lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Cornwall updated HARMONY-6065:
-------------------------------------
Comment: was deleted
> [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
>
> 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.
[jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates
bad lookupswitch code 25% of the time
Posted by "Andrew Cornwall (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661377#action_12661377 ]
Andrew Cornwall commented on HARMONY-6065:
------------------------------------------
It looks as if tableswitch has the same problem (VMTT should insert 0 bytes padding, but instead inserts 4 bytes padding.)
> [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
>
> 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.
[jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates
bad lookupswitch code 25% of the time
Posted by "Alexei Fedotov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12677591#action_12677591 ]
Alexei Fedotov commented on HARMONY-6065:
-----------------------------------------
Andrew, please verify the fix.
> [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.