Hello to all, For those of you who may have the mails from the issue tracker and/or the reviews filtered, I am copying here the text from issue #3001 [1], which I have posted a moment ago.
--- --- --- ---
Allowing to customize which functions V8 would use for system
heap memory allocation in a per-Isolate basis would allow for
a number of things to be done:
* Tracking memory usage (and other metrics, e.g. fragmentation),
with different purposes. A real-world case I can provide is
monitoring and remotely reporting memory usage of applications
which are run in separate Isolate each, in the same process.
* Easily replacing the standard system allocator. This can be
interesting for platforms where the malloc/free functions
provided by the system C library are known to be slow. As
an example, traditionally the Windows C runtime memory
allocation functions have been orders of magnitude slower
than alternate implementations like tcmalloc or nedmalloc.
* Using V8 in platforms with unusual memory layouts or with
imposed constraints. For example, systems with small amounts
of memory may use an allocator which reduces fragmentation
as much as possible (in this case being slower may be a better
option than running ouf of memory). Another example is systems
which do not provide standard memory allocation functions (or
do not have a “traditional” memory layout).
* Simulating out-of-memory conditions for stress testing V8
in such an scenario. For example this is interesting for
the development of the garbage collector itself.
* Debugging memory usage of V8 by using an allocators that
return memory initialized certain data pattern, or which
allocate around page boundaries to catch accesses outside
of the allocated memory chunks.
* Any other you can think of :-)
--- --- --- ---
I also wrote some notes (also posted to issue #3001) on how the
implementation from my “isolate-alloc” branch works [2]. My plan is
to submit code reviews for the commits in that branch, and use the
issue for tracking overall progress. Reading this overview should
help the review process (or so I hope ☺)
Internal changes
----------------
The internal SystemHeapAllocator class provides utility functions.
The v8::SystemHeapAllocator class exposed in the public API (see below)
can be casted to this internal one.
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/src/allocation.h#L49
The SystemHeapAllocatorObject class is intended to be used as a base
class for objects which are allocated via a SystemHeapAllocator. The
class defines custom new/delete operators. Allocation is done via
placement-new, and the allocator will embed a pointer to itself in
the allocated memory area, so the delete operator can retrieve it to
perform the deallocation.
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/src/allocation.h#L87
SystemHeapAllocated is meant to be used as base class for objects
that are to be allocated using SystemHeapAllocator. It defines
operators to use placement-new with a SystemHeapAllocator, and
an allocator-aware Delete<T>() template function that must be used
instead of global delete operator. Using the delete operator on
objects derived from SystemHeapAllocated will (conveniently) cause
a compiler error. Contrary to SystemHeapAllocatorObject, this class
does *not* incur in additional memory being used to store the pointer
to the allocator. Therefore, this is used as base class whenever
possible.
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/src/allocation.h#L128
The Array<T> template provides the static functions Array<T>::New() and
Array<T>::Delete(), which work with SystemHeapAllocator and are meant to
replace NewArray<T>() and DeleteArray<T>().
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/src/allocation.h#L221
Last, but not least, the Malloced class is removed, as it is not needed
anymore: All uses of Malloced have been replaced by SystemHeapAllocated,
or by other means of memory allocation. (Also, check "Other notes" below).
Changes to (de)allocation sites
-------------------------------
A a number of classes which were allocated using new/delete were modified
to use the new per-Isolate allocation facilities. Wherever possible, the
versions that accept an Isolate are used, which more clearly states the
idea that the allocated objects belong to a particular Isolate.
Note that the changes done cover a bit less than 50% of the uses of objects
allocated on the heap (as of 2013/11/09). I will keep updating this issue
work progresses.
Public API changes
------------------
The SystemHeapAllocator class defines methods to be used to allocate
memory from the system heap. To define a custom allocator, client code must
subclass SystemHeapAllocator.
Functions v8::SystemHeapAllocator::{get,set}Default() access a static
global which is preinitialized to an allocator (LibcSystemHeapAllocator)
that uses the system C library malloc() and free() functions.
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/include/v8.h#L3914
A new overloaded Isolate::New(SystemHeapAllocator*) function allows to define
which allocator is to be used for a newly-created Isolate. Allocations of
memory from the system heap will be done using it (including the Isolate
object itself). The existing Isolate::New() function uses the allocator
that can be obtained with SystemHeapAllocator::getDefault().
→ See: https://github.com/aperezdc/v8/blob/isolate-alloc/include/v8.h#L3994
-Adrian
---
[1] https://code.google.com/p/v8/issues/detail?id=3001
[2] https://github.com/aperezdc/v8/tree/isolate-alloc/
pgpGRQ61xOC6l.pgp
Description: PGP signature
