harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates bad lookupswitch code 25% of the time
Date Fri, 27 Feb 2009 23:07:13 GMT

    [ 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.


Mime
View raw message