jkeiser's mozilla blog

Static Linking

Quick log of memory investigations for the day:

Static Linking

It turns out that several of our modules are not currently statically linked. This means there are a bunch of optimizations linkers can't do, and a bunch of strings that are necessarily put into programs that link against those dlls that can't be stripped. On a tiny platform (which is a big reason to be concerned about bloat) you're not going to need those libs to be shared.

Fragmentation

Turning off frame arenas (by defining DEBUG_TRACEMALLOC_FRAMEARENA) doesn't seem to keep fragmentation down much. But now that I think more seriously about how an OS would do memory allocation, I think I understand why that would be. At least if pagesize is small, frame arenas should actually keep fragmentation down. In fact, as I write this I begin to question whether the numbers we have been reading for the amount of size the app takes up are accurate--the VmSize of GtkEmbed was up to 29M with an apparent 10Mb of fragmentation, and the size reported in top was 17-19M (I forget which). Therefore it would seem that that number is not reported, when it really needs to be for a small target. Or is this a red herring? Maybe what you'd do to kill fragmentation problems on a small device is just set pagesize frighteningly small. I need to investigate this.

I learned how /proc/*/maps works today (tells you what dll has what memory allocated for it), so it's time to start correlating those results with trace-malloc and see what kind of objects are left around in mostly-empty pages and where they are left around. It's my theory (perhaps wrong) that a ton of objects are created when you load a document and some of those objects are kept around for the next document (caches and the like). For a small target, they shouldn't be.

Hard Size Limits (Memory Pressure)

Another really interesting idea to come out of today's myriad discussions was to have a pref to enforce a "pretty hard limit" on our size. In other words, when we get near that limit (say within 200K?), documents will stop creating content nodes and frame construction will abruptly halt. We can't do anything about people creating new strings, but I'm sure. This pref will help us develop to smaller targets and, as Kevin points out, some users might want it on their machines anyway. The trick is to make sure we don't leak, because that would get ugly with such a pref.

Events

On an unrelated note, I found the problem with events: it relates directly to the fact that we do not store the event target in the event. But shocker of shockers, fixing the problem causes more, eviler problems in events which seem to be related to the same root cause (storing the event target in all sorts of hairy places). I'm investigating, but I begin to suspect we may have to back out the mouse events patch and fix targets to be stored in the event itself (where it should have been all along!) in 1.4alpha.

Posted by jkeiser at February 6, 2003 8:30 PM