----- "Christopher Blizzard" <[EMAIL PROTECTED]> wrote: > Jason Evans wrote: > > Christopher Blizzard wrote: > > Also a perfectly valid question: how many apps will want to worry > about > the savings that jemalloc provides? Many long-running apps (like a > browser?) Memory-sensitive apps (like mobile apps?) We'll need to > have > a guide here. Some apps probably won't care that much, but many > will. > Right now, mostly longer-lived applications and ones that want finer-grain control over how much free space is held on to by the allocator. Given that fragmentation effects are going to be different from application to application you'd really need to measure each one.
> Do we have decent measurements of the benefits of jemalloc as part of > of > the larger picture of our memory improvements leading up to FF3? Some > > of it was fixing allocations but a lot of it came from a well-tuned > allocator. Just wondering what we should tell people here. > On Windows jemalloc reduced our heap size by about half. On Linux, I believe it was closer to 5% on average although I've seen higher (~10%) numbers with various tests. We also saw a pretty big perf wins on our various tests when we turned it on (8% on Tp for example). > > > >> So I have a concern about this from an embedding standpoint. If > we're > >> using jemalloc's allocator instead of the normal system one, how > will > >> this affect apps that want to link against libxul or the library > that > >> we provide for embedding? Specifically: > >> > >> 1. If the jemalloc allocator gets loaded, does it change the > allocator > >> used by the app? If so, does that happen after the app has done > some > >> allocations and might cause mis-matched malloc/free pairs? > > > > As things currently work, if libxul is a load-time library > dependency > > for the application, then having jemalloc embedded is fine, because > > > jemalloc will override the system malloc before any allocations > happen. > > > > However, my understanding is that that some applications use > dlopen(3) > > to load libxul on the fly, which causes horrible problems if > jemalloc is > > part of libxul. This is why I think we need to make jemalloc a > separate > > library, and also require any application that dlopen()s libxul to > be > > linked against libjemalloc. This is a rather onerous requirement, > but I > > can't think of any reasonable alternative, if jemalloc is to be used > at > > all. (Incidentally, it shouldn't be hard to programmatically > enforce > > this requirement.) > > There are some applications that will do that, sure. And that sure > would be some bad mojo. I suspect that given this and the fact that > we're going down the route of having good support for embedding that > we > should revisit how we're linking in the jamalloc code so that we get > the > cases right. > > Ben, do you have any issue with that? > > It's also important to note that the original bug in question was a > performance bug. Can anyone think of a way we can avoid the perf > problem that the change was originally designed to avoid? > The perf hit we believe was simply due to yet-another-dynamic-library needing to be loaded. It was small (1%?) and I wouldn't worry about it much -- we can get much bigger startup wins elsewhere. > > > > If jemalloc were used privately by libxul (jemalloc not exposed), > then > > embedding applications would have to use some special deallocation > API > > in order to work with objects that originate from within libxul. > > Additionally, libxul would either have to copy externally allocated > > > objects to internally allocated memory, or jump through some other > > hoops, like checking where objects came from in key places. This > mixed > > allocator model would be pretty bad from a fragmentation (and > probably > > speed) perspective. > > Yeah, uhh, ick. Yeah, it is important the main app link against jemalloc in one way or another. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
