On 12/22/2014 07:51 AM, Filip Pizlo wrote:
On Dec 22, 2014, at 4:28 AM, Phil Bouchard <pboucha...@gmail.com
<mailto:pboucha...@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.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
