tcmalloc status of OS_ANDROID and ARM64

[kui]

Hi,

I find tcmalloc is disabled on OS_ANDROID by default (correct me). Considering many benchmarks shows tcmalloc is faster, for example; http://goog-perftools.sourceforge.net/doc/tcmalloc.html. Do you know:

1. Will tcmalloc be as default allocator on Android in future? 

2. Is anybody working on tcmalloc ARM64 bit enabling?

Thanks in advance,

-Kui

[Harry Shan]

AFAIK, on android we have dlmalloc as default. 

I don't have data comparison in Chrome but here is a article: http://webkit.sed.hu/blog/20100302/war-allocators-qtlaunchers-coast

We can see in most cases, tcmalloc is faster but dlmalloc consumes less memory. Almost all difference is within 5%.

I suppose Google thinks on android devices, less memory usage matters :)



在 2014年10月20日星期一UTC+8下午4时49分56秒，kui写道：

[Kui Zheng]

Thanks Harry's response, Seems it's a balanced solution. I'm curious which allocator is most fit for Common Browser memory usage In theory. for example V8 GC, DOM node, Skia or CC rendering object.

For tcmalloc arm64bit enabling, I just created one Chromium issue: https://code.google.com/p/chromium/issues/detail?id=423298 . 

[Primiano Tucci]

Yes, Harry response is pretty much accurate. The thread-caching feature of TCMalloc ends up using slightly more memory and last time somebody benchmarked it wasn't much faster than Android's dlmalloc.  I cannot find the bug with the data right now, but it's there somewhere on crbug.com :=)

> I'm curious which allocator is most fit for Common Browser memory usage In theory. for example V8 GC, DOM node, Skia or CC rendering object.

Note that the situation is a bit more complicated. There isn't a single allocator in Chrome. There is a default allocator. Some projects have their own allocator which is independent of whether the default one is TCMalloc or the system one. For instance Blink recently switched most of its code paths to use its own partition allocator (see third_party/WebKit/Source/wtf/PartitionAlloc.h).

Therefore, whatever change you make to the default allocator is not going to impact those parts which use a custom allocator.

> For tcmalloc arm64bit enabling, I just created one Chromium issue: https://code.google.com/p/chromium/issues/detail?id=423298 . 

Do you have any data / benchmark that shows how faster vs how fatter (w.r.t. memory usage) is it?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Kui Zheng]

Thanks a lot, It's much clear.

> For tcmalloc arm64bit enabling, I just created one Chromium issue: https://code.google.com/p/chromium/issues/detail?id=423298 . 

Do you have any data / benchmark that shows how faster vs how fatter (w.r.t. memory usage) is it?

I'm looking at Chromium Memory usage on ARM64bit platform (compare to 32 bit) . No data so far, actually, I try to profile overall memory using DMP tool (http://dev.chromium.org/developers/deep-memory-profiler) that relies on tcmalloc, but seems 64bit is not supported by tcmalloc so far. (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmalloc/chromium/src/base/atomicops-internals-arm-v6plus.h&sq=package:chromium)