Rob Kendrick wrote: > On Tue, 27 Apr 2010 11:09:32 +0100 > Rik Griffin <[email protected]> wrote: > >> In message <[email protected]> >> Rob Kendrick <[email protected]> wrote: >> > >> > I've CCed the netsurf-dev list with this, as it might be interesting >> > for the non-RISC OS developers, as an insight into restrictions we >> > have to keep in mind if we want to continue supporting RISC OS. I >> > hope you don't mind. >> >> One partial solution springs to mind for all this - use more dynamic >> areas. Say one area per page, then when when Netsurf discard the >> page, destroy the DA as well. Maybe extra DAs for cached content as >> well? > > The trouble here is that there are loads of pieces of data, handled by > vastly different pieces of code, and some of these pieces of data are > shared between pages. (String internment springs to mind. Also, do we > share identical images with identical URLs which happen to appear on > more than one open page?) Also, it'd complicate all the code that > allocates memory quite significantly.
If you have lots smallish objects with a wide range of lifetimes you can massively reduce fragmentation by using a pool allocator of some sort to collect objects of a similar lifetimes into larger chunks of memory. I've seen techniques such has this solve address space fragmentation issues we had with a project on 32 bit linux. In the case of RISC OS, the C runtime won't give the memory back, but at least it will be less fragmented and, hopefully, the total memory used will be less. Also, having lots of DAs filling up the address space is probably not going to play well with RISC OS 5 which reserves a larger chunk of the address space for applications (up to 1 GB?) James
