[Webkit-unassigned] [Bug 21272] Switching between custom allocators (TCmalloc, JEmalloc) in linux-qt

[bugzilla-daemon at webkit.org]

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





--- Comment #20 from Kwang Yul Seo <kwangyul.seo at gmail.com>  2010-02-09 10:19:13 PST ---
(In reply to comment #19)
> Custom allocation framework is ready (only few (<5) classes aren't inherited
> from FastAllocBase), so you can safely use custom allocators - trough
> FastMalloc - without overriding global operator new/delete.
> Now, I'm benchmarking JEmalloc on multi-threaded benchmarks,  tomorrow I'll
> write a post about the results. 
> 
> First, I think we should make TCmalloc's implementation WinCE compatible, and
> test that. Adding and maintaining an extra allocator - because of one platform
> - is not a good idea.
> 
> What are the depedencies of enabling TCmalloc on WinCe? TCmalloc uses
> pthreads... This might be a problem, isn't it?

I agree with you. TCmalloc needs to be ported to WinCE before we consider
adding an extra allocator.

Implementing threading and spin lock for WinCE ARM is one thing, but the big
obstacle is the WinCE's virtual memory space limitation. WinCE is unique as it
allows only 32MB virtual memory space to each process. Windows CE 6.0 Embedded
removed the limitation though.

Check out the memory map of Windows Mobile 6.1 (based on Windows CE 5.0)

http://bolingconsulting.com/blog/?p=4

Fortunately, VirtualAlloc(size > 2MB) allocates the memory outside the 32MB
process virtual memory space. It allocates memory in Large Memory Area(LBA).
TCmalloc must be modified to address this issue.

Mozilla's Fennec uses jemalloc to overcome this virtual memory space issue as
jemalloc is ported to WinCE to circumvent the limitation.

My colleague is currently working on this issue. He will be able to submit a
patch soon or later.

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