Hacker News Reader

While not right square on topic I dont think the parent post was so off target compared to digressions and explorations that are common on discussions here that it warranted an admonishment. I have not "worked on modern browsers" and that seems to disqualify me from expressing an opinion on what I consider using too much as an user of a piece of software.

But this much I can say, that even a few years back I could comfortably use a Linux desktop on 64MB RAM. Now even a Debian box with X would run rather choppily on a system that has 256MB and it is not very clear to me in what exact way is my compute experience better now than the one that I had on the 64MB system. Even those that are considered a lean browser, take upto 200MB of that 256 and still does not work smoothly.(FF 3.5 still does fine on this system BTW). Had my old system been augmented with some 3Gigs of RAM it is possible that its performance would be worse than a modern system of equivalent RAM, but now that it is common for a system to occupy more resources to accomplish the same level of activity is at times an irritant.

The usual counterargument is that RAM is cheap and one should just go and buy some or suffer otherwise. I think it is this assumption that is made or a requirement that is imposed by the newer versions of software that GP was complaining about.

"Comfortably use" my eye. Web browsers have always been bulky by the standards of their day. I remember using IRIX on a 64MB SGI Indy and cursing. It thrashed swap furiously with Netscape 4.

Today's agony always seems new and fresh, but it never is. I still have some of those old systems sitting around to remind me. The "good old days" were pretty miserable.

Today I have Linux and Firefox and the exact same problems -- in 1G of RAM, which is a comparably low-spec system today to what the Indy was back then. The more things change, the more they stay the same.

> • There's very often a speed / memory usage tradeoff. At present, especially for web browsers, users tend to prefer speed. (i.e. how many rendered pages do you cache per tab so that clicking the back button is next to instant?)

This is a good point, and the amount of memory used for such a cache is ideally "all of it, but no more".

Which is the same argument for buffer cache.

So I wonder if it's possible to use the buffer cache in this way?

Perhaps write the rendered image to a tmpfile. Then don't sync the write and also something like fadvise(FADV_DONTNEED). The app can then free the memory. (Clearly you could play a similar game with mmap()).

The idea would be to have the memory sitting in the system buffers. But the app can inform the system that these pages are discardable under memory pressure, rather than needing to be written to disk.

What's being cached in the "rendered page" case is not an image but an object graph in memory.

Writing that to disk involves either fixing up all the pointers on read or making sure you can read it all back into _exactly_ the same locations in your virtual address space or something. This can still improve performance over creating the object graph from scratch (c.f. XDR for Gecko's JavaScript or Mozilla's fastload stuff for the user interface), but not nearly as much as just having the object graph there.

One other note: just because _you_ don't sync the write doesn't mean some other random part of your app, or some other app, won't.... and then you have extra disk traffic.

Well, you either serialise/deserialise your data structure to make it memory relative, or you could use mmap().

Allocate such pages with a malloc which works out of an anonymous mmap() backed pool, with madvise(MADV_DONTNEED).

The OS will then discard the pages under memory pressure and will give you back zero filled pages if they have been discarded.

If each object has a nonzero sentinel value and is smaller than a page, you can detect discarded objects.

Objects bigger than a page can be composed of a 'dictionary obj' which pts to multiple objects - check the sentinel on each and discard/rebuild the whole lot if any are missing.

That last bit may be hard to retrofit, I agree.

The latter doesn't really solve the problem. Folks are still going to see that Firefox is using a lot of memory, even if the OS is now more inclined to swap out pages that are less important.

I think it solves the technical problem, I agree that there is an potentially an issue of perception. (Note that the OS won't swap these pages, it will discard them under memory pressure).

(Although an argument could be made that any the OS need not account pages which a process has marked as DONTNEED as "belonging" to that process). In as much as a page does "belong" to a process, anyway.

> Well, you either serialise/deserialise your data structure > to make it memory relative

Yes, aka "fix up all the pointers".

> or you could use mmap()

That doesn't help: the objects in the DOM are already allocated on the heap. You just want to hold on to them and then drop those references at some point. Writing a pointer to a heap object to disk, even via mmaped memory areas, isn't going to really work well.

And you can't just drop the objects from the heap because they may have references from elsewhere to them.

> That doesn't help: the objects in the DOM are already allocated on the heap. You just want to hold on to them and then drop those references at some point.

The idea is to have more than one heap, with different behaviour. Objects in one heap have a "can disappear at any time, but we can detect that" behaviour.

An 'object deep copy' is all it takes to move an object from one heap to another. Or if you prefer, you can allocate all such objects in the discardable heap but temporarily 'pin' an object by changing the madvise on it's pages (this involves more page-level complexity of how stuff is laid out and how pages are shared between objects).

I'm not saying this is a 2 hour project, but it's the sort of thing which could be captured in a library without too much complexity.

> Writing a pointer to a heap object to disk, even via mmaped memory areas, isn't going to really work well.

You'd be surprised. I've done exactly this [1]. As long as your mmap'd addresses are stable, it's fine. Also note that in the case we're talking about,the pages never go to disk. They're in anonymous-backed mmap'd memory, which the kernel has been told to throw away instead of writing to disk (swap in this case, since this is an anon map).

[1] well, pretty close. I made a single-proc app multi-proc by making it's key data structures allocate out of a pool controlled by a custom malloc, backed by a mmap()'d disk file. Other processes then attached to that file via mmap() at the same address and lo and behold, all the pointers to the nested data structures were good. (One proc had read/write access to this pool, the others were all readonly. Some additional locking was required. Your mileage may vary.)

You're right in that things won't work if something else has a ptr to these pages. But as long as all references to such pages go via a single "get_page_from_cache()" it's fine.

> You're right in that things won't work if something else > has a ptr to these pages.

That's the problem, exactly. In a browser context it's pretty easy for something else (another frame, a web page in another tab or window) to have pointers into the DOM of pages that have been navigated away from. So when a page is evicted from the in-memory cache some of the information can just be destroyed. The layout objects, say. These are already allocated out of an arena, so the mmap approach may work there; it's worth looking into. But the DOM can't just be unmapped (and in fact is not arena-allocated for the same reason right now) unless you're willing to pin the whole mmaped area if something holds on to those objects, which brings us back to fragmentation issues.

"There's very often a speed / memory usage tradeoff."

And yet Firefox seems to use about 4 or 5 times more memory than Chrome on my system whilst being noticably slower as well...

If Chrome had all the addons that Firefox had, Firefox would be a dead browser.

I still use Firefox as my primary browser. For now.

I have the inverse of your situation that chrome always use much more memory than firefox.

That's because 1) Chrome is better-designed 2) Chrome extensions are JS and not native code, meaning they're less likely to leak due to programmer error, and there are fewer of them, to boot

> 2) Chrome extensions are JS and not native code, meaning they're less likely to leak due to programmer error, and there are fewer of them, to boot

Are there really that many Firefox extensions that use native code?

Side note: Firefox extensions aren't native code, they're written in JS.

EDIT: I do however agree that chrome is more well designed. Firefox has been through a lot of iterations through the years.

While most Firefox extensions are in JS, I believe you can bind to native c++ as well.

Chrome also allows you to access native code in extensions using NPAPI plugins: http://code.google.com/chrome/extensions/npapi.html

I remember sometime back probably around 2004. There was a lot of noise regarding memory leak in FF. And the expert sounding ones started to claim that there was no memory leak and the very large memory usage in FF was because of browser history and cache storage. Then one year later they all accepted that FF was actually leaking memory.

Since then I stopped accepting expert opinion blindly.

Experts are sometimes wrong. That doesn't change the fact that they're right vastly more often than non-experts.

I could be wrong, but wasn't a large part of this due to Flash?

I think it turned out that a large part of it was due to, like, 100 different small things. There was never a memory leak.

There is an important difference between "expert-sounding" and "expert".

Where memory leaks (or pretty much any performance metric) are involved, the more sure someone sounds, the less likely they are to be an expert unless they have done extensive measurements to back up their claims.