[webkit-dev] Memory Manager
pbouchard8 at gmail.com
Mon Dec 22 05:29:54 PST 2014
On 12/22/2014 07:51 AM, Filip Pizlo wrote:
>> On Dec 22, 2014, at 4:28 AM, Phil Bouchard <pbouchard8 at gmail.com
>> <mailto:pbouchard8 at gmail.com>> wrote:
>> On 12/22/2014 02:04 AM, Myles C. Maxfield wrote:
>>> “Manager” is a vague term. Do you mean a replacement for malloc() /
>> - It handles cyclic pointers so it's really a memory manager.
> None of the documentation explains how you do this. I’d need something
> akin to a proof to believe that you’ve solved this problem.
This is a good presentation on how it handles it:
You basically have "sets" of memory blocks (i.e. container = 1 set). If
you merge the sets they become one big set. When the last pointer from
the stack is deleted then the entire set is also destructed.
>> - It's deterministic because you can predict when all memory blocks
>> will get deallocated
>> - All memory allocations are guaranteed to be free when the
>> application terminates
> This last bit doesn’t matter. Instead, what matters, is that any object
> that dies can rapidly be deallocated regardless of the lifetimes of
> other objects. In particular, region-based memory management would be
> unacceptable for our purposes. I have a vague guess that you’ve
> reinvented regions.
No it's different than regions:
The block pointer will destroy objects and call their destructor as soon
as possible. It is based on a standard smart pointer for objects and
sets. The size of each pointer = "sizeof(void *) * 2".
>>> Is there any documentation or explanation of your implementation?
>> Yes, in the aforementioned link:
>>> Why are you confident that WebKit would see speed improvements using
>>> this library?
>> I am currently working for a company that uses Webkit and most of the
>> time the browser hangs because of the current garbage collector.
> That’s a rather extreme claim. Have you filed any bugs for this issue?
> It’s true that our GC can stop the world. We could fix that by making
> the GC concurrent or incremental. I’d welcome any patches in that
>>> What about your memory manager indicates that WebKit would be a good
>>> choice of user of it?
>> Why would Webkit be a good choice? Because it can improve the overall
> It depends on what you mean by performance. You haven’t actually
> explained what you mean by it. Do you mean pause time? Utilization?
> Throughput? Memory usage?
The overall performance; there won't be any moment where the browser
stops and collects the garbage thus hanging the process.
> Note that we care about memory usage and throughput the most, with pause
> times and utilization being a close second. Probably going forward
> we’ll switch to caring about all four of them about equally. We cannot
> sacrifice one to get the others.
>>> Are there any other libraries that use it? Which version(s) of Boost
>>> is/will this be included in?
>> It is still pending for review:
>> But it's already been unit tested so it is operative:
> You would need a tremendous amount of evidence to convince us that this
> is usable for our purposes. Our GC may have its performance issues but
> it is very robust.
I understand that but the garbage collectors have been tested for
decades. The block pointer is just freshly baked and is already functional.
>> The only thing left to be done is to use a faster pool than the
>> current Boost one.
>> allocations are guaranteed to be freed instantly. So if the memory is
>> somehow exhausted; you just have to reload the page.
> We generally strive to ensure that users don’t have to restart the web
I'm just talking about the worst case scenario here but when the garbage
collector kicks in on a small set-top box the whole system is easily frozen.
How many times the garbage collector will kick in when you use the
browser for a week on a set-top box? At least once a day, hopefully not
when you're watching the 4th quarter of an important football game.
More information about the webkit-dev