harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Cornwall (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-6065) [drlvm][testing] VMTT generates bad lookupswitch code 25% of the time
Date Tue, 06 Jan 2009 21:01:44 GMT

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


Mime
View raw message