[webkit-dev] Memory Manager

[Phil Bouchard]

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() /
>>> free()?
>>
>> - 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:
https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/BlockPointer.ppt

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:
http://en.wikipedia.org/wiki/Region-based_memory_management

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:
>> https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/index.html
>>
>>> 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
> direction.
>
>>
>>> 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
>> performance of the Javascript handler.
>
> 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:
>> http://www.boost.org/community/review_schedule.html
>>
>> But it's already been unit tested so it is operative:
>> https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/example/
>
> 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.
>>
>> Keep in mind that every time a Javascript page terminates, all memory
>> 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
> process.

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.