Ein neuer Memory-Allocator dürfte (neben der Verringerung der internen XPCOM-Aufrufe) evtl. sogar die wichtigste Performance-Optimierung in Firefox 3 sein, oder?

Zum Hintergrund: Das Problem der dynamischen Speicherverwaltung in Multithreaded-Anwendungen ist "nicht trivial". Ein linearer Speicherbereich muss von mehreren Threads gleichzeitig benutzt werden können, ohne dass das notwendige Locking der gemeinsam genutzten Verwaltungs-Strukturen das gesamte Programm ausbremst. Die bekannteste Optimierung ist z.B., den linearen Speicherbereich in Bereiche aufzuteilen, die dann (möglichst ohne Locking) exklusiv nur von jeweils einem bestimmten Thread verwendet werden können. Dann muss man sich aber natürlich Gedanken darüber machen, was passiert (und wie man das feststellen kann), wenn ein Speicherbereich, den ein Thread alloziert hat, plötzlich von einem anderen Thread verwendet (z.B. dealloziert) werden soll.

(Die dynamische Speicherverwaltung mit malloc() usw, auch unter C++, läuft ja komplett im User-Level ab, weshalb man da im Prinzip für jedes Programm die am besten passende Implementierung wählen kann. Der Kernel wird in der Regel nur angewiesen, den zugeordneten linearen Speicherbereich zu vergrößern oder zu verkleinern - siehe "man brk(2)".)