[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 #6 from Geoffrey Garen <ggaren at apple.com>  2009-09-15 15:46:56 PDT ---
> 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.

I can see some value there. But, like I said, your patch makes the problem
you're trying to solve worse, by adding another #if without removing any.

> 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.

What would you do when memory was 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.

I don't think that's a good direction to go in. On most systems, it will cause
huge page fault and paging overhead.

> > 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.

If you want to optimize for clients that expect to make more calls for
allocations of the same sizes, just add an explicit API for pools.

I don't think a pool would be a good idea in the case of collector blocks,
because a block is already a pool, and the collector already manages a pool of
blocks, based on information that it has and the VM allocator does not have,
like total GC heap size.

> > 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.

OK, but like I said before, you've increased complexity rather than decreasing
it.

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