Updates:
Owner: [email protected]
Labels: Type-FeatureRequest Priority-Low
Comment #1 on issue 847 by [email protected]: 1gb memory limit
http://code.google.com/p/v8/issues/detail?id=847
There two independent issues we need to solve to support large heaps:
1) Currently V8 uses int variables/fields to track various limits inside
memory management subsystem. Limits overflow when heap size approaches 1gb
and this causes erratic behavior [e.g. Heap::old_gen_allocation_limit_
overflow forces V8 always to select mark-sweep collector instead of
scavenge].
Semantically correct fix for this would be to replace int with size_t in
appropriate places. Unfortunately this requires serious refactoring of V8
source code because currently it consistently uses int to store sizes of
various objects and changing some of this declarations to use size_t will
cause to numerous "signed compared to unsigned", "signed stored to
unsigned" errors.
2) MarkCompactCollector and MemoryAllocator use encodings based on
assertion that number of chunks constituting paged part of the heap does
not exceed certain value and each chunk consists of limited number of pages
of limited size [see comments for Page::opaque_header and MapWord class].
One needs to rewrite these parts of GC/allocator to raise heap limits.
An independent problem is GC throughput: while current V8 GC behaves well
on small and medium heaps [and especially on applications that satisfy
generational hypothesis] it's performance could degrade on large heaps. For
example on 1.5Gb heap one should expect mark-sweep taking > 1 s,
mark-compact taking > 3s and scavenge taking >50ms. Such pauses might
significantly degrade overall application performance and responsiveness.
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
