Bug 46252 – [Qt] [WebKit2] Shared memory design should be improved

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: WebKit2

[Balazs Kelemen]

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.

[Balazs Kelemen]

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.

[Kenneth Rohde Christiansen]

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

[Balazs Kelemen]

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

[Andras Becsi]

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

[Siddharth Mathur]

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.

[Balazs Kelemen]

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

[Balazs Kelemen]

This job has been done by http://trac.webkit.org/changeset/76507

*** This bug has been marked as a duplicate of bug 51984 ***