>>13
I was thinking of mark-compact:
http://en.wikipedia.org/wiki/Mark-compact_algorithm
This allows constant-time allocations and doesn't waste half the memory doing so. Essentially the heap becomes a huge dynamic array that gets resized in amortized constant time.
>>17
You mean this thread? It's around 20KB right now. 5MB for that would be huge --- 250 bytes per byte. (I'm assuming you mean 5MB for the HTML DOM and associated data structures, not including the code.)
>>19
I'd probably only support one active tab at a time
What UI supports multiple active tabs?
The biggest source of complexity is probably the interaction of the JS with the DOM, since you want the DOM to be represented in some memory-efficient format they would not correspond to JS objects necessarily. JS can manipulate the DOM in many different ways and you would have to handle memory allocation/deallocation appropriately (e.g. a node that was created only by JS and not in the original page, would need to be freed once JS disposes of it.) Writing a browser that just renders static HTML is almost trivial in comparison.