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] Created: (HARMONY-6065) [drlvm][testing] VMTT generates bad lookupswitch code 25% of the time
Date Tue, 06 Jan 2009 20:59:44 GMT
[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