On Tue, Mar 04, 2014 at 09:48:33AM +0200, Henri Sivonen wrote: > 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?
its generally gcc that does dumb things with static initializers, but that can generally be fixed with liberal use of constexpr. Anyway I suspect the real answer is "it's complicated" ;) but it's probably a good idea at least for things on the staart up path anyway adding a relocation and saving a call to malloc before we can parse html is probably a win on its own. > > 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 aiui yes the heap is made copy on write at the time fork(2) is called to create the Nuwa process, and presumably we don't have KSM turned on so only the initial heap will ever be shared. I'd guess that HTML parser stuff you mentioned is created beforewe fork the Nuwa process and so its included. > 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? probably not perfectly, but it seems like in practice it does fairly well other wise Nuwa wouldn't help. Trev > > -- > Henri Sivonen > hsivo...@hsivonen.fi > https://hsivonen.fi/ > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform
signature.asc
Description: Digital signature
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
