608203 - ABC: Add a means of creating Array, ByteArray, and Vector data from a literal list of values

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect)

Description

[Lars T Hansen]

Currently an initializer for aggregate data can be represented in two ways:

- as code, eg:
   pushint; pushint; ...; newarray
   newarray; dup; pushint; setprop; dup; pushint; setprop; ...

- as string data
   pushstring

It would probably be helpful for both performance and ABC compactness if we had a more general facility wherein the ABC could carry a sequence of values and operate on these as a group to create the aggregate data.

For example, consider this array initializer:

  [1,3,5,7,11,13,17,19,23,27]

This could be represented as a sequence of integer values in the int constant pool and a new instruction, which I will call NEWARRAY3, which takes a constant pool identifier, a start index in that pool, and a number of consecutive pool elements and creates the array:

  newarray3 0, 7, 10

Similarly there could be instructions to construct ByteArray and Vector.<int>, Vector.<uint>, and Vector.<Number> data.

Comment 1

[Kyle Murray]

Wouldn't such a format potentially increase the size of the constant pool by a fair amount?  Currently, I thought that the constant pools never had duplicates (for example, you would only have one 42 in the pool, and instructions using 42 would all reference 42's single index in the pool).

You'd run into at least two kinds of duplication:

     [1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] // where you have the same number repeated

and

     [2, 0xdeadbeef, 4], [17, 0xdeadbeef, 4] // where two arrays share a weird constant

That problem intensifies with things like string-filled arrays, where you'd have to duplicate repeated strings in the pool if you wanted to have unique ranges for each initializer.  

This proposed newarray3 would certainly compact the size of bytecode blocks within MethodBodyInfos, but it's hard for me to make a good guess about whether it would help or hurt the overall ABC size.  Perhaps the compression of the SWF would eliminate any size concerns about the constant pools.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.