mirror of
https://github.com/LadybirdBrowser/ladybird
synced 2026-04-27 18:17:22 +02:00
Instead of storing a u32 index into a cache vector and looking up the cache at runtime through a chain of dependent loads (load Executable*, load vector data pointer, multiply index, add), store the actual cache pointer as a u64 directly in the instruction stream. A fixup pass (Executable::fixup_cache_pointers()) runs after Executable construction in both the Rust and C++ pipelines, walking the bytecode and replacing each index with the corresponding pointer. The cache pointer type is encoded in Bytecode.def (e.g. PropertyLookupCache*, GlobalVariableCache*) so the fixup switch is auto-generated by the Python Op code generator, making it impossible to forget updating the fixup when adding new cached instructions. This eliminates 3-4 dependent loads on every inline cache access in both the C++ interpreter and the assembly interpreter.
13 lines
520 B
Plaintext
13 lines
520 B
Plaintext
JS bytecode executable ""
|
|
[ 0] 0: GetLexicalEnvironment dst:reg4
|
|
[ 8] GetGlobal dst:reg6, identifier:f
|
|
[ 20] Call dst:reg5, callee:reg6, this_value:Undefined, f, arguments:[Int32(1)]
|
|
[ 48] End value:reg5
|
|
|
|
JS bytecode executable "f"
|
|
[ 0] 0: GetLexicalEnvironment dst:reg4
|
|
[ 8] JumpUndefined condition:arg0, true_target:@18, false_target:@40
|
|
[ 18] 1: Mov dst:arg0, src:<Empty>
|
|
[ 28] ThrowIfTDZ src:arg0
|
|
[ 30] Mov dst:arg0, src:arg0
|
|
[ 40] 2: End value:Undefined |