Full Article Attached Major Roadmap Update Centers Around Phoenix, Thunderbird; 1.4 Branch to Replace 1.0; Changes Planned for Module Ownership Model

Wednesday April 2nd, 2003

In the most radical change to the Mozilla project since the late 1998 decision to rewrite much of the code, today announced a major new roadmap proposal that will see Phoenix and Thunderbird (also known as Minotaur) becoming the focus of future development. According to the roadmap, 1.4 is likely to be the last milestone of the traditional Mozilla suite and the 1.4 branch will replace the 1.0 branch as the stable development path. is also proposing changes to the module ownership model including a move towards stronger leadership and the removal of mandatory super-review in some cases. Please click the Full Article link to read the full analysis.

#95 Memory mapping

by leafdigital

Thursday April 3rd, 2003 5:11 AM

You are replying to this message

You're thinking pre-386 :>

With current computers, memory mapping means you can map the same loaded code (read-only block of memory) into the address space of two different processes. So the *code* of the GRE (a DLL, I presume, on Windows) would only need to be loaded once. However, the *data* of the GRE would be stored separately for each process.

So total memory consumption now:

GRE code + GRE data + Mozilla code + Mozilla data

Total memory consumption in the new scheme:

GRE code + GRE data + Phoenix code + Phoenix data + GRE data + TBird code + Tbird data

This is why, even though sharing the same GRE code, one instance can't crash the other one - the only shared part is the GRE code, and you physically *can't* mess up the GRE code because it is stored in a read-only memory block. [Well, ideally. I'm not sure whether the OS enforces this by default and there are ways to defeat it. :)]