Include handle in bytecode data segment metadata #113
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, we ship a JSON data structure with bytecode templates called `meta` that is keyed on specifier string and contains the component's VM handle and symbol table. This data structure supports dynamic lookup of components via the `{{component}}` helper, even though most component invocations are precompiled in bytecode mode.
However, we currently don't serialize each component's handle, which is an application-specific identifier. Handles are used to allow opcodes to refer to "live" JavaScript objects, like component classes, at runtime. While handles are built into the compiled bytecode, they are not accessible to dynamic component invocation. This means that Glimmer.js apps have to ship both the module resolution map as well as the template metadata just to get an app to boot, which is wasteful.
This commit adds each component's handle to its metadata entry in the compiled data segment. It also updates the BytecodeResolver to use the handle and external module table, so resolution happens identically to the static invocation path. In addition to this resolution being faster, it also means that Glimmer.js apps can boot without a resolution map and use the bytecode metadata for everything.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, we ship a JSON data structure with bytecode templates called
metathat is keyed on specifier string and contains the component's VM handle and symbol table. This data structure supports dynamic lookup of components via the{{component}}helper, even though most component invocations are precompiled in bytecode mode.However, we currently don't serialize each component's handle, which is an application-specific identifier. Handles are used to allow opcodes to refer to "live" JavaScript objects, like component classes, at runtime. While handles are built into the compiled bytecode, they are not accessible to dynamic component invocation. This means that Glimmer.js apps have to ship both the module resolution map as well as the template metadata just to get an app to boot, which is wasteful.
This commit adds each component's handle to its metadata entry in the compiled data segment. It also updates the
BytecodeResolverto use the handle and external module table, so resolution happens identically to the static invocation path. In addition to this resolution being faster, it also means that Glimmer.js apps can boot without a resolution map and use the bytecode metadata for everything.