46252 2010-09-22 02:16:01 -0700 [Qt] [WebKit2] Shared memory design should be improved 2011-01-25 10:03:34 -0800 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) PC All RESOLVED DUPLICATE 51984 P2 Normal --- 1 kbalazs webkit-unassigned abecsi kenneth koivisto laszlo.gombos s.mathur zherczeg zoltan oldest_to_newest 282856 0 kbalazs 2010-09-22 02:16:01 -0700 In 4594 a heated debate had been started about the shared memory implementation. We should reconsider how to allocate the shared memory and how to release it on exit. 282861 1 kbalazs 2010-09-22 02:24:24 -0700 We already have a platform independent shared memory implementation: QSharedMemory. I do not understand why we do not use that. I remember that Kenneth told me that it has some problems with releasing the allocated area. Please explain the arguments against QSharedMemory in more details. 283020 2 kenneth 2010-09-22 10:14:56 -0700 (In reply to comment #1) > We already have a platform independent shared memory implementation: QSharedMemory. I do not understand why we do not use that. I remember that Kenneth told me that it has some problems with releasing the allocated area. > Please explain the arguments against QSharedMemory in more details. 1) It is limited to 2MB on mac and it is not something normal users are going to change 2) If an app crashes the shared memory is not freed, so we will have even less memory What do you have against I/O mapped memory? The memory is never being written to disk/flushed and we do not have any limit. 283065 3 kbalazs 2010-09-22 11:10:09 -0700 > 1) It is limited to 2MB on mac and it is not something normal users are going to change I think this should be fixed in QSharedMemory with the trick we are using. > 2) If an app crashes the shared memory is not freed, so we will have even less memory Really? If all of the processes died or terminated that using the shared memory then the OS reclaims it, isn't it? > > What do you have against I/O mapped memory? The memory is never being written to disk/flushed and we do not have any limit. I find the files somewhat useless since on linux or windows you can allocate virtual address space without underlying files. If you cannot do it on mac then I am fine with the I/O mapped memory. (A comment should be added about that.) Anyway, we should fix the problems you mentioned in 4594. 285454 4 abecsi 2010-09-27 07:44:37 -0700 (In reply to comment #0) > In 4594 a heated debate had been started about the shared memory implementation. The discussion started in https://bugs.webkit.org/show_bug.cgi?id=45984. 310837 5 s.mathur 2010-11-18 06:46:32 -0800 BTW, on Symbian OS there is no native concept of a file-mapped virtual memory AFAIK, so the only correct way to do shared memory in a scalable and performant way is to either: a) Use QSharedMemory (which uses Symbian OS RChunk, the entry point into kernel's memory management features) b) Use RChunk API directly in case QSharedMemory's RChunk usage is too simplistic or inefficient for Webkit'2 demanding needs. 311361 6 kbalazs 2010-11-19 04:48:07 -0800 (In reply to comment #5) > BTW, on Symbian OS there is no native concept of a file-mapped virtual memory AFAIK, so the only correct way to do shared memory in a scalable and performant way is to either: > a) Use QSharedMemory (which uses Symbian OS RChunk, the entry point into kernel's memory management features) > b) Use RChunk API directly in case QSharedMemory's RChunk usage is too simplistic or inefficient for Webkit'2 demanding needs. I vote for QSharedMemory. We are also using it in the SharedMemory class. 339710 7 kbalazs 2011-01-25 10:03:34 -0800 This job has been done by http://trac.webkit.org/changeset/76507 *** This bug has been marked as a duplicate of bug 51984 ***