On Fri, Feb 28, 2014 at 8:09 PM, L. David Baron <dba...@dbaron.org> wrote: > In other words, whenever you have a pointer in a static data > structure pointing to some other data, that pointer needs to get > fixed up when the library loads, which makes the memory that pointer > is in less likely to be shared across processes (depending, I guess, > on how many processes are able to load the library at its default > address, which may in turn depend on security features that try to > randomize library base addresses). This also slows down loading of > shared libraries.
So all things considered, do we want things like static atoms and the HTML parser's pre-interned element name and attribute name objects (which have pointers to static atoms and a virtual method) to move from the heap to POD-like syntax even if it results in relocations or, with MSVC, static initializers? > Shouldn't be an issue with Nuwa-cloned processes on B2G, though. Are static atoms and the HTML parser's pre-interned element name and attribute name objects that are on the heap shared between processes under Nuwa already? I.e. is the heap cloned with copy-on-write sharing? On the memory page granularity, right? Do we know if the stuff we heap-allocate at startup pack nicely into memory pages so that they won't have "free" spots that the allocator would use after cloning? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
