Conversation
Replace formatMemoryWord (heap-allocating string) with writeMemoryWordRaw that writes 0x-prefixed hex directly to the JSON stream, eliminating per-word allocations in debug_traceBlockByNumber with enableMemory=true. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
AskAlexSharov
approved these changes
Apr 23, 2026
…emory_dump_in_streaming
lupin012
deleted the
lupin012/fix_debug_traceBlockByNumber_with_memory_dump_in_streaming
branch
lupin012
added a commit
that referenced
this pull request
Apr 24, 2026
… (cherry-pick) (#20787) This PR addresses issue #20738 by optimizing how memory words are processed during tracing. Optimization: Replaced formatMemoryWord (which creates a new string on the heap for every word) with writeMemoryWordRaw. Mechanism: Hex data with the 0x prefix is now written directly to the JSON stream. Impact: Significant reduction in GC pressure and elimination of per-word heap allocations, which should prevent OOM crashes during large block traces. With debug_traceBlockByNumber on block 0x17AEF7D: main releases: All memory(128G+32G) is used then OS kill it for OOM branch release: Memory used stable 10G Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
lupin012
added a commit
that referenced
this pull request
Apr 24, 2026
close #20738 This PR addresses issue #20738 by optimizing how memory words are processed during tracing. Optimization: Replaced formatMemoryWord (which creates a new string on the heap for every word) with writeMemoryWordRaw. Mechanism: Hex data with the 0x prefix is now written directly to the JSON stream. Impact: Significant reduction in GC pressure and elimination of per-word heap allocations, which should prevent OOM crashes during large block traces. With debug_traceBlockByNumber on block 0x17AEF7D: main releases: All memory(128G+32G) is used then OS kill it for OOM branch release: Memory used stable 10G Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
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
2 participants
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.
close #20738
This PR addresses issue #20738 by optimizing how memory words are processed during tracing.
Optimization: Replaced formatMemoryWord (which creates a new string on the heap for every word) with writeMemoryWordRaw.
Mechanism: Hex data with the 0x prefix is now written directly to the JSON stream.
Impact: Significant reduction in GC pressure and elimination of per-word heap allocations, which should prevent OOM crashes during large block traces.
With debug_traceBlockByNumber on block 0x17AEF7D:
main releases: All memory(128G+32G) is used then OS kill it for OOM
branch release: Memory used stable 10G