[webkit-dev] Memory Manager

[Filip Pizlo]

> On Dec 22, 2014, at 4:28 AM, Phil Bouchard <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.

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

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

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

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

-Filip

> 
> 
> Regards,
> -Phil
> 
>> Thanks,
>> Myles
>>> On Dec 21, 2014, at 8:53 PM, Phil Bouchard <pbouchard8 at gmail.com> wrote:
>>> 
>>> Greetings,
>>> 
>>> I wrote a deterministic memory manager in C++ and I was wondering if their is any interests introducing it into Webkit, thus speeding up Webkit.
>>> 
>>> The memory manager is located here:
>>> https://svn.boost.org/svn/boost/sandbox/block_ptr/
>>> 
>>> 
>>> Sincerely yours,
>>> -Phil
>>> 
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
> 
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20141222/8e9cf612/attachment.html>