1# 2022-08-18-isa-changelog 2 3This document describes change log with the following modifications: 4 5* ISA refactoring 6* Function Kind and Header index 7* MethodId, StringId and LiteralArrayId 8* LiteralArrayIndex refactoring 9 10## ISA refactoring 11The bytecode size and runtime performance have been suffering for a long time as the all the 12ecmascript specific bytecode are prefixed and their opcode were encoded with two bytes. 131. We delete all original java specific opcodes and delete java specific opcode prefix. 142. We remove the prefix of ecmascript specific opcodes, such that most of the bytecode opcode can be encoded with one byte. 153. We add prefix "deprecated" and keep the many old isa as "deprecated"-prefixed opcodes (for compatibility). These prefixed opcode will be deleted once we do not need to concern compatibility. 164. We add prefix "throw" and make all throwing opcodes be prefixed by "throw". 175. We add prefix "wide" to support opcodes which need larger immediate number. 186. We adjust the format of some opcodes (about immediate number and accumulator), so that the bytecode can be more compact. 197. We change the semantics of some opcodes. 208. We add 8-bit or 16-bit imm as inline cache slot for some specific opcodes. 21 22## Function Kind and Header index 23As we merge some "define-function" opcodes as one opcode, in function we add one field which records the function kind, 24such that runtime can distinguish the "define-function" operations of different kinds. 25We also add header index in function such that runtime can access IndexHeader more efficiently. 26We reuse the field 32-bit field `access_flags_` to encode Function Kind and Header index. 27This will not introduce compatibility issue because the later 24-bit of `access_flags_` is unused indeed. 28Now the layout is: 29 30|<- 16-bit header index ->|<- 8-bit function kind ->|<- 8-bit original access flag ->| 31 32## MethodId, StringId and LiteralArrayId 33To adapt runtime design, we put string and literal array into the index header of methods, 34such that the instructions can get consective indexes for methodId, stringId and literalarrayId. 35This will help runtime to build constant pool more efficiently. 36As the method number in a class is not limited, we release the constraint that all methodId, 37stringId and literalarrayId in a class should be put in a same index header. 38Instead, we only ask that all methodId, stringId and literalarrayId in a method should be put in one index header. 39As we use 16-bit to encode methodId, stringId and literalarrayId, the number of these Ids in one method cannot exceed 65536 for now. 40This released constraint suits for most of application scenarios. 41 42## LiteralArrayIndex refactoring 431. We deprecate the usage of global literalarray index. 442. We use offset to reference literalarray. 453. In bytecode, we still use 16-bit literalarrayId rather than offset. 464. The layout of literalarrays can be random. 475. The literalarray which is referenced by TypeSummary contains the offsets of all type-literalarray. 48