> On Dec 22, 2014, at 2:29 PM, Phil Bouchard <philipp...@gmail.com> wrote: > >> 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.
Yup, you reinvented regions. > >>> - 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". You can call it whatever you like, but I'll call it regions. (This isn't the first time a region memory manager had unification or destructors. RTSJ had destructors and MLKit had unification. The literature on regions is extensive. Pretty much everything has been tried.) > >>> >>>> 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. Instead there will be many moments when the browser crashes because it ran out of memory. > >> 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. And the block pointer doesn't work for JSC and probably never will. For example each object's set will be unified with the set of its structure, which will be unified with the empty object structure, which in turn will be unified with the global object. Then the global object will be unified with its parent global object, and its internal objects will be unions with all of the internal types hanging off VM. So, everything will become a member of one giant set and the VM will leak memory and never free anything. The reason why we use GCs instead of regions is that regions are well understood as an impractical approach to general memory management. > >>> >>> 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. Your approach means that in the middle of the football game the browser will crash. I think that if you're concerned with this scenario, you should implement a concurrent GC. I would be happy to provide some guidance on how to do it; I've had a plan for this for a while now. -Filip _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
