CodeCache: function-executable cache entry + depth-bounded eager generation - #344
Draft
Jarred-Sumner wants to merge 3 commits into
Draft
Jarred-Sumner wants to merge 3 commits into
Jarred-Sumner wants to merge 3 commits into
Conversation
…ble cache entry Adds a depth parameter to the recursive unlinked-code-block generators (0 = top-level block only, N = N levels of nested functions, default unbounded = previous behavior) and Options::bytecodeCacheMaxDepth, on top of the CachedFunctionExecutable cache entry for function executables (needed for builtin modules, which are compiled as functions rather than programs).
Preview Builds
|
Alignment padding in encoded pages was left as allocator garbage, which made cache blobs vary byte-for-byte between runs. Zeroed pages make the padding deterministic; a remaining ASLR-derived leak (a few words in a handful of entries) is tracked separately.
HandlerInfoBase::typeBits was a 2-bit bitfield whose 30 padding bits were never written, and UnlinkedHandlerInfo's default constructor left start/end/target uninitialized. The exception-handler vector is serialized bytewise into the bytecode cache, so cache blobs were not reproducible (and carried stack garbage). Make typeBits a full-width, default-initialized field and zero the rest of the default ctor.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Two additions needed to cache builtin-module bytecode in Bun (builtins compile as function executables, and only their top-level block is worth caching):
CachedFunctionExecutableTagtop-level cache entry (encodeFunctionExecutable/decodeFunctionExecutable/sourceCodeKeyForSerializedFunctionExecutable,recursivelyGenerateUnlinkedCodeBlockForFunctionExecutable) — this is the change from JSC: add a bytecode cache entry for UnlinkedFunctionExecutable #270, rebased ontomain.depthparameter threaded through the recursive unlinked-code-block generators (generateUnlinkedCodeBlockForFunctions,recursivelyGenerate…ForProgram/ModuleProgram/FunctionExecutable) plusOptions::bytecodeCacheMaxDepth(0= top-level code block only,N= N levels of nested functions,-1= unbounded, which stays the default so existing callers are unchanged).generateProgramBytecode/generateModuleBytecodehonor the option, sobun build --bytecodecan bound its blob size too.Depth 0 turns out to be the right point for Bun's builtins: the whole corpus (194 modules, 2.5 MB source) encodes to 3.0 MB vs 12.0 MB fully recursive, and the parse it removes is almost entirely the whole-file parse of each module's top-level block.
Supersedes #270.