Refactor bytecode representation

[raskad]

This PR changes the bytecode encoding / decoding, the bytecode emitting and the opcode execution logic.

In addition to this change in bytecode encoding, I took the chance to add two further changes:

1. Move arguments decoding into defined central types. This enables us to reuse arguments decoding code and geet rid of alot of the per opcode boilerplate that was error prone to write manually.
2. Generate emit functions for every opcode that can be used in the bytecompiler to get rid of error prone manual emit code.
3. Move the handling of different CompletionTypes into the opcode code itself. This results in the CompletionType enum being removed. This moves the handling code out of the hot loop that is iterating trough the opcodes. Also many opcodes can only return a limited possibility of completions. Moving the handling into the opcodes enables a more specific handling, in some cases basically removing any handling at all.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	50,254	50,254	0
Passed	46,857	46,857	0
Ignored	1,634	1,634	0
Failed	1,763	1,763	0
Panics	0	0	0
Conformance	93.24%	93.24%	0.00%

[raskad]

This is not finished in any way. I just wanted to put it out to get some feedback on the overal concept. All of the flowgraph / trace code is still missing from the new appoach. If the feedback is positive, I will see how to best implement that / possibly also move into macros. In addition spend_budget_and_execute is also not implemented yet and some arguments are not represented optimally (I wanted to see if there are performance gains first, before spending more time on that).

To get an overview / feeling for the changes:

• look at some changes in the bytecompiler code for the new emit code.
• look at some individual opcode files for the execution code
• see some of the major changes in core/engine/src/vm/opcode/mod.rs and core/engine/src/vm/opcode/args.rs.

[HalidOdat]

Really liking the direction of this PR, simplifying the arguments and generating the opcode functions is a great step forward. 😄

That said, I did notice that the bytecode size increases by about 3x (based on checking the combined.js output). While some of that overhead might be reduced by encoding multiple instructions into a single one, it's still likely to end up at least twice as large overall. Additionally, splitting the bytecode into two arrays could have a negative impact on cache locality.

Overall, I think the approach we're taking is aligned with what engines like V8 and JavaScriptCore are doing. There's a great article from the JavaScriptCore team that touches on a similar idea with prefix opcodes: A new bytecode format for JavaScriptCore.

In terms of performance, I suspect the bigger issue isn't so much unaligned reads, but rather how we read arguments — currently it's done one at a time, with a bounds check on each access. We might see a noticeable performance boost if we check bounds ahead of time and read the arguments in bulk.

Would love to hear your thoughts! :)

EDIT: Here is the code I used to get the size :)

• https://github.com/HalidOdat/boa/tree/main-bytecode-size-check
• https://github.com/HalidOdat/boa/tree/refactor-bytecode-u64-wip-size-check

[raskad]

In terms of performance, I suspect the bigger issue isn't so much unaligned reads, but rather how we read arguments — currently it's done one at a time, with a bounds check on each access. We might see a noticeable performance boost if we check bounds ahead of time and read the arguments in bulk.

I think that is probably the case. I switched back to the u8 bytecode format and I still get a slight performance increase in my first tests.

Switching back to the u8 format was much easier with the new macro based opcode emit functions and the new opcode execution dispatching. So I think just for that it would make sense to merge this.

[HalidOdat]

Awesome work! Really love the removal of the execute_* functions with arguments definitions and the type-safe compiler functions 🤩

Just had some comments on how we could improve it, see if they make any sense, the rest looks good to me :)

[HalidOdat]

This PR resolves #2561 🥳

[nekevss]

nit (non-blocking): add some unit tests here or an issue should be opened to add tests for the unsafe code here.

Still working my reading through this, so I'm familiar with it. 😆 It may come up in the future if we have some unsafe code here but no unit tests in the module. I wouldn't block merging this on lack of tests, but if none are added, we should at least open up an issue. Plus, adding the unit tests themselves could make a good first issue for someone looking to contribute.

[raskad]

Definitely. I will open an issue after the merge.

[raskad]

#4240

[HalidOdat]

Besides the nitpick, this looks perfect to me! 😄