543879 - [Jaeger] Analyze Nitro & V8 code memory management

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

For bug 543878, we should study the competition to get an idea of the design space and what has worked for others.

Comment 1

[David Mandelin [:dmandelin]]

I took a look at this today. First, JSC:

Memory for code comes from an ExecutableAllocator. This in turn manages ExecutablePool objects. An ExecutablePool is a pool of memory that allocates with a bump allocator. Allocation in that pool fails if there is not enough space. The ExecutableAllocator has methods to make pages writable (and not executable) or executable (and not writable). This is mostly managed automatically by RepatchBuffer and LinkBuffer objects.

The policy is this:

 - Create a 4-page ExecutablePool for small code chunks on startup.
 - To allocate a code buffer larger than 4 pages, create a fresh ExecutablePool of the exact right size.
 - To allocate a code buffer smaller than 4 pages, use the current small page pool. If it does not have enough room, create a new pool, make that the current small page pool, and allocate from there.
 - Reclaim pools using reference counting. The ExecutableAllocator has one reference to the current pool. Otherwise, CodeRef objects hold the reference to the pool for a given chunk of code.
 - Crash on OOM.

Thus, the lifetime of a chunk of code is at least as long as the script it was compiled for, but it tries to reclaim code memory not too long after the script goes away.

Comment 2

[David Mandelin [:dmandelin]]

Now, V8:

V8 uses the GC for code memory. The GC is pretty interesting in itself but I don't want to go into too much detail here. See spaces.h for more info. The basics are that they have a young generation which has two semispaces and uses copying GC. When an object has already been moved or the to space is 25% full during copying, the object is promoted to an old space. There are multiple old spaces, which are mostly mark-compact. There is a separate old space for large objects that doesn't move things.

There is an old space specifically for code. It is limited in size to 2 GB so that all calls and jumps can use 32-bit displacements, even on x64. The old space is given a logical size of 1GB on desktop platforms, but it doesn't allocate that right away. Instead, it grows as needed. Code buffers are allocated using a malloc-like allocator, but cleaned up with the mark-compact collector. Code carries relocation information so that displacements can be patched as needed in the compaction process. The code space is made executable, and presumably can be kept non-writable when not being written to.