100% CPU usage - V8 StringTable performance collapse
Status Fixed / completed
Maintainer reply None cached
Activity 8 comments · opened Oct 26, 2025 · closed Nov 25, 2025
process_info.txt
sample1.txt
sample2.txt
sample3.txt
sample4.txt
<img width="672" height="545" alt="Image" src="https://github.com/user-attachments/assets/0b1e8d6b-cff6-47e6-9bfa-390e376f8ee7" />
Claude Code 100% CPU Bug
Summary
Claude Code node process (PID 29085) consuming 98-100% CPU indefinitely due to V8 StringTable performance issue.
Environment
- OS: macOS 26.0.1 (25A362)
- Node: /opt/homebrew/Cellar/node/24.10.0/bin/node
- Claude Code: 2.0.27
- Parent Process: npm exec @anthropic-ai/claude-code@2.0.27
- Working Directory: /Users/max/hobby/mac/bgc
- Memory: 3.2GB → 3.5GB physical footprint (growing)
- Uptime: 17+ minutes at 100% CPU
Root Cause Analysis
Sample 1 (Initial)
- Heavy ICU (International Components for Unicode) garbage collection
icu_77::RuleBasedBreakIteratordestructors- Memory deallocation in ICU library
Sample 2 (Follow-up) - Primary Issue
V8 String Table performance collapse:
Array.map →
SetKeyedProperty →
StringTable::LookupString →
String::SlowEquals (996+ samples)
CompareCharsEqual (328+ samples per call)
KeyedStoreIC_Megamorphic →
StringTable::TryStringToIndexOrLookupExisting
ObjectPrototypeHasOwnProperty →
StringTable lookups
JSON.stringify →
JsonStringifier::SerializeStringSample 3 (10-second, Confirmation)
Memory growth confirmed: 3.4GB → 3.5GB peak
V8 heap expansion detected:
PagedSpaceBase::TryExpandMemoryAllocator::AllocatePagemmapsystem calls for new pages
Same StringTable bottleneck (worse):
StringTable::LookupString- 2541 samplesString::SlowEquals- 1000+ samples- Hash table rehashing under load
Issue is stable and worsening over time.
Performance Anti-Pattern Detected
- Megamorphic property access - V8 IC (Inline Cache) deoptimization
- String table overload - thousands of unique string keys
- Linear string comparison -
String::SlowEqualswith byte-by-byte comparison - Hash table rehashing -
NameDictionary::Rehashduring object property additions
Call Stack Pattern
RunMicrotasks →
Promise chains →
Array.map (on large dataset) →
Object property assignments with dynamic keys →
V8 string internalization →
Linear search in string table →
Byte-by-byte string comparisonLikely Trigger
Code is processing large arrays with:
- Dynamic object key creation
- Heavy use of
hasOwnProperty - JSON stringification
- ICU text segmentation (word/sentence breaking)
Impact
- 100% CPU usage on single core
- Process unresponsive
- Memory gradually increasing to 3.2GB
- System thermal throttling
Reproduction
Unknown - occurred during normal Claude Code operation in /Users/max/hobby/mac/bgc directory.
Files Attached
sample1.txt- Initial 5s sample showing ICU GC (1.1MB)sample2.txt- Follow-up 5s sample showing V8 StringTable issue (138KB)sample3.txt- Confirmation 10s sample showing memory growth (295KB)process_info.txt- Process details- Screenshot showing Activity Monitor CPU usage (pending)
8 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Update: Process Terminated After Sample 4
Final stats before termination:
Sample 4 added (999KB, mem: 4.1GB peak) - shows continued V8 StringTable bottleneck with no improvement.
Memory leak confirmed - process consumed 1.8GB additional memory over 22 minutes while stuck in string comparison loops.
Sample Files
All sample files and process info available in this gist:
https://gist.github.com/kuzmeech/7e649d3d57b4a0aac853f09e9a90c1fc
Files included:
sample1.txt(1.1MB) - Initial 5s sample, mem: 3.2GBsample2.txt(138KB) - Follow-up 5s sample, mem: 3.2GBsample3.txt(295KB) - 10s sample, mem: 3.5GBsample4.txt(999KB) - Final 10s sample, mem: 4.1GBprocess_info.txt(696B) - Process detailsThis is NOT a duplicate. While symptoms are similar (100% CPU, memory growth), the root causes are different:
#1554 (v1.0.10, Jun 3 2025, ~5mo old): Generic freeze, no root cause identified
#4580 (v1.0.61-1.0.62, Jul 25-28 2025, ~3mo old): JSON serialization recursion (2000+
JsonStringifier::Serialize_calls)#8968 (v2.0.8, Oct 4 2025, 21d old):
StringPrototypeSplitheap exhaustion#10349 (this issue, v2.0.27, Oct 24 2025, 1d old): V8 StringTable performance collapse
StringTable::LookupStringbottleneck (2541 samples in 10s)String::SlowEqualslinear searchicu_77::RuleBasedBreakIterator)Evidence quality difference:
Version timeline: Different root causes manifesting across 5 months (Jun → Oct 2025), indicating multiple distinct performance bugs with similar symptoms. This issue reports the latest version with most detailed profiling data.
Actionable intel: This identifies a specific V8 string table hash collision scenario during dynamic object key creation with ICU text processing.
Not a duplicate - this is a distinct performance anti-pattern requiring targeted optimization.
Becomes superslow for me after some time working. Not clear the cause but forces to restart the CLI. Showing in latest versions. 2.0.25 -> 27 (Windows 11 here)
Also happening for me on v2.0.46 2.4ghz 8core intel i9, 64gb 2667MHz DDR4, MacOS Sequoia 15.4
Closing - not reproducible in Claude Code 2.0.53. Will reopen if issue resurfaces.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.