4 ms·

Have you guys SEEN the respective code bases for Mozilla and WebKit? Really, this was inevitable. Their whole tabs-as-process thing is too, when you think abou

Have you guys SEEN the respective code bases for Mozilla and WebKit? Really, this was inevitable. Their whole tabs-as-process thing is too, when you think about it. Just imagine the potential for a browser-as-OS-with-processes-and-everything and how much they must be salivating to get it on devices and desktops NOT running Windows. It's a hell of a trojan horse in their winning battle to make Microsoft irrelevant... And open source? <3

tlrobinson 18y ago
"Have you guys SEEN the respective code bases for Mozilla and WebKit?" I haven't... can you elaborate?
- kilowatt 18y ago
  Basically, WebKit is the most immediately understandable large scale C++ codebase I've ever seen. They have a strict culture of code reviews on check-in, and reverting any changesets that cause regressions. My commits have been rejected for style--I was first pissed, and eventually impressed :P I can't speak for Mozilla's collaborative culture (and the fact that Firefox emerged from Netscape means it can't be half-bad), but just on an aesthetic level, WebKit C++ is a lot easier on the eyes than Mozilla. One thing that's interesting about WebKit is that in the last 12 months when I've been pulling upstream changesets from them, I've noticed that they're not afraid to do project-wide renames to keep the code clean. It seems like a small thing, but it's a lot more approachable to see clean C++ that uses namespaces and abstracts away platform differences in a coherent way. Mozilla is full of COM interfaces like #define NS_IHTML_CSS_STYLE_SHEET_IID \ {0xb5cc4ac0, 0xeab6, 0x11d1, {0x80, 0x31, 0x00, 0x60, 0x08, 0x15, 0x9b, 0x5a}} class nsIHTMLCSSStyleSheet : public nsIStyleSheet ... and so on. edit: To be fair, I'm just a lot more familiar with WebKit, so maybe someone can defend (or pick apart) Mozilla's sources better than I can. If you check out WebKit, you'll also notice that there's an impressive collection of 210MB(!) of individual layout tests.
  - ii 18y ago
    Mozilla/Gecko is not just a browser engine, it's a platform (XPCOM) and everything is implemented on top of this platform as XPCOM components/interfaces. The bad thing is that these components are not very easy to use, write and integrate into anything else.
nailer 18y ago
> Their whole tabs-as-process thing is too, when you think about it. Could you please explain this too? I like being able to identify and kill individual tab and plugin processes. But I don't understand why you can't garbage collect a thread like the presentation seems to say.
- lacker 18y ago
  You can't kill a single thread safely because threads of the same process have shared memory. For example, a thread might be in the middle of some operation that's destructive if it's aborted when only half finished. If this seems unlikely, think of adding an element to a hash table used by many threads and having to resize it, copying all the old elements to the new one. If you kill the thread in the middle of the resize (which might take a while if it's allocating a lot of memory) then all the other threads that use that hash table will get screwed up. There's also no good way to tell which memory is being used by which thread. Often the whole point of threads is that they use shared memory; in this case the memory bloat might be _caused_ by a single thread but end up bloating a data structure that is _shared_ by all threads. By giving each tab its own process, Chrome uses more memory to start out with - each process must have its own data structures for some things which in normal browsers are in shared memory - but hopefully in the long run it will avoid memory leaks.
- jmtulloss 18y ago
  It's because there isn't a compacting garbage collector running. The core is C/C++, so it relies on the OS allocator to keep memory from becoming fragmented. The OS allocators are good, but they aren't that good. In a browser you're constantly allocating and freeing large amounts of memory, so you're going to end up with some holes. Its usage pattern is way different than most applications because it's used like Google finally designed it: as a window into a bunch of different processes.
  - nailer 18y ago
    Thanks.

tlrobinson 18y ago

"Have you guys SEEN the respective code bases for Mozilla and WebKit?" I haven't... can you elaborate?

kilowatt 18y ago
Basically, WebKit is the most immediately understandable large scale C++ codebase I've ever seen. They have a strict culture of code reviews on check-in, and reverting any changesets that cause regressions. My commits have been rejected for style--I was first pissed, and eventually impressed :P I can't speak for Mozilla's collaborative culture (and the fact that Firefox emerged from Netscape means it can't be half-bad), but just on an aesthetic level, WebKit C++ is a lot easier on the eyes than Mozilla. One thing that's interesting about WebKit is that in the last 12 months when I've been pulling upstream changesets from them, I've noticed that they're not afraid to do project-wide renames to keep the code clean. It seems like a small thing, but it's a lot more approachable to see clean C++ that uses namespaces and abstracts away platform differences in a coherent way. Mozilla is full of COM interfaces like #define NS_IHTML_CSS_STYLE_SHEET_IID \ {0xb5cc4ac0, 0xeab6, 0x11d1, {0x80, 0x31, 0x00, 0x60, 0x08, 0x15, 0x9b, 0x5a}} class nsIHTMLCSSStyleSheet : public nsIStyleSheet ... and so on. edit: To be fair, I'm just a lot more familiar with WebKit, so maybe someone can defend (or pick apart) Mozilla's sources better than I can. If you check out WebKit, you'll also notice that there's an impressive collection of 210MB(!) of individual layout tests.
- ii 18y ago
  Mozilla/Gecko is not just a browser engine, it's a platform (XPCOM) and everything is implemented on top of this platform as XPCOM components/interfaces. The bad thing is that these components are not very easy to use, write and integrate into anything else.

nailer 18y ago

> Their whole tabs-as-process thing is too, when you think about it. Could you please explain this too? I like being able to identify and kill individual tab and plugin processes. But I don't understand why you can't garbage collect a thread like the presentation seems to say.

lacker 18y ago
You can't kill a single thread safely because threads of the same process have shared memory. For example, a thread might be in the middle of some operation that's destructive if it's aborted when only half finished. If this seems unlikely, think of adding an element to a hash table used by many threads and having to resize it, copying all the old elements to the new one. If you kill the thread in the middle of the resize (which might take a while if it's allocating a lot of memory) then all the other threads that use that hash table will get screwed up. There's also no good way to tell which memory is being used by which thread. Often the whole point of threads is that they use shared memory; in this case the memory bloat might be _caused_ by a single thread but end up bloating a data structure that is _shared_ by all threads. By giving each tab its own process, Chrome uses more memory to start out with - each process must have its own data structures for some things which in normal browsers are in shared memory - but hopefully in the long run it will avoid memory leaks.
jmtulloss 18y ago
It's because there isn't a compacting garbage collector running. The core is C/C++, so it relies on the OS allocator to keep memory from becoming fragmented. The OS allocators are good, but they aren't that good. In a browser you're constantly allocating and freeing large amounts of memory, so you're going to end up with some holes. Its usage pattern is way different than most applications because it's used like Google finally designed it: as a window into a bunch of different processes.
- nailer 18y ago
  Thanks.