[Webkit-unassigned] [Bug 29256] Use MemoryManager to gather platform-specific low level memory requests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=29256





--- Comment #5 from Yong Li <yong.li at torchmobile.com>  2009-09-15 14:43:58 PDT ---
(In reply to comment #4)
> What's the goal of this patch? JavaScriptCore already supports malloc/free and
> Windows.
> 

One goal is to finally remove those #if PLATFORM(...), #if HAVE(MMAP) and #if
HAVE(VIRTUAL_ALLOC) things from other source files. Like CurrentTime.cpp, we
use WTF::currentTime() everywhere, so we don't have to put the following code
everywhere.

 #if PLATFORM(POSIX)
 ... gettimeofday
#elif PLATFORM(WIN)
 ... GetSystemTime
...

Another goal is try to gather all low-level memory requests together, so that
at runtime we can have a better view of the memory usage, and can do something
special when it fails to allocate more, or when memory is under pressure.

I also have an idea about lazy memory freeing for OwnPtr and RefPtr. That could
boost performance. To make it work perfectly, we need to get notified upon
memory allocation failure. in MSVC, there's a _set_new_handler() that can be
used to do cleanup when malloc or new fails. It should be doable to add such a
callback to fastMalloc implemenation. So at the time we cannot allocate more
memory, we have to free those delayed memory blocks immediately.

All of such things need a memory manager that takes control of overall memory
usage.

Another benefit of memory manager is that it makes customization easier. People
don't have to modify those JavaScriptCore source code for each special port.


> 1. There's a layering problem. An "abstract" memory allocator should be
> agnostic about the kinds of allocations its clients will make. But this
> allocator has functions like allocateJSBlock and reserveJSRegisterFile, tying
> it to its clients. This seems like a confused and unscalable design.
>

I was using more common functions like allocateVirtualMemory. But then it could
be hard to optimize. For example, Collector.cpp allocates 256K JS blocks. If
MemoryManager knows about it's for JS, then it may allocate a big chunk of
memory (2M for example), and cut them into 256k blocks as a pool for JS.

> 2. You haven't ported any existing platforms to the abstract interface, so
> you've just added yet another way to allocate memory, complicating the design.

I provide a MemoryManagerWin.cpp. It compiles, but it includes
runtime/Collector.h. I think it's up to win32 developer to decide to use or not
use it.

I also provide a MemoryManagerPseudo.cpp, which provides a simple solution for
RegsiterFie, MarkStack and JS blocks, without real virtual memory.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.