Hacker News Reader

Comment by jarin | Hacker News Reader

I wonder if that's been fixed in the OS X/Darwin version of Mach, seems like the only time I ever reboot my MacBook is for system updates.

View on HN

While the discussion in that thread may or may not apply to OS X, be very careful when saying "X is true about Mach therefore X is probably true about Darwin". A friend of mine put it very well:

OS X was Mach once in the same way that orcs were elves once.

The original poster in that thread was running 10.5.8. No one in the thread posted saying that they couldn't repro the port leak. The thread is quite recent, the latest post being from earlier today.

I think we have to assume that the port leak is still there in the most recent version (10.6.6).

I do hope that the poster had misunderstood Avie Tevanian in his conversations with him. Tevanian was one of Apple's chief architects and was one of the big wheels responsible for NextStep's transformation to OS X. It would be kind of outrageous for an OS architect to believe that it's at all acceptable to allow user-mode processes to cause kernel resource leaks.

It was an engineering trade-off like any other. Would you be willing to reboot your computer once a month if it meant everything would be 1000x faster? Of course. So were the Mach designers, apparently.

Except that I've looked at a lot of OS memory management code and the savings are not 1000x.

You're misinterpreting the post; Mikel wasn't talking about the same leak the original thread was. He was just talking about how he fixed a leak many years ago.

Using Mach ports correctly without leaking is hard, similarly to how using C's malloc/free without leaking is hard. The former no more implies a current flaw in Mach than the latter implies a current flaw in C stdlib.

Kernels should not have resource leaks. A web server that leaks memory implies nothing wrong with the clients, a kernel that leaks memory implies nothing wrong with the user space programs.

It just means that there are cases that the kernel developers didn't think of, just like the people who made Apache didn't think of the Slowloris attack. Heck, a few months ago someone exhausted Linux kernel fds in just by shuffling socket pairs around (just 40 lines of C with three syscalls).

These are problems, ranging from remote DOS attacks, local DOS attacks, to accidental DOS attacks.

I wonder if there's an update for my MkLinux box!

http://mklinux.org/

Wow. There are still MkLinux users? What's the motivation?

Hurd not being ready.

This: the only time I ever reboot my MacBook is for system updates

Seems to indicate that it has ;-)

really man? maybe you are not using your macbook long enough or you are simply browsing the internet with it?

I reboot my macbook pro (running leopard) as often as I reboot my windows 7 PC which is not much. Except I use the Win7 machine 90% of the time and for much more "intensive" stuff.

I use it probably 14+ hours a day, and it's variously running MySQL, Redis, MongoDB, Photoshop, 600 million Chrome tabs, Xcode and Starcraft 2 whenever possible :)

I did experience memory leaks with pretty much every Bittorrent client, but I haven't torrented any uh, Linux distros in forever.

Just asking, but how do you keep so many Chrome tabs open without things getting sluggish? My MBP (2008 pre-unibody/Leopard) seems to get bogged down with just a couple score of Chrome tabs.

Granted, I don't know much about what's going on under the hood (I'm a designer, not a programmer) but Activity Monitor shows that each tab uses a gig of virtual memory...

Just a guess, I think there might be some APIs available in SnowLeopard that allow Chrome to write its tabbed content to files and read it in asynchronously more easily than they could have in Leopard. Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again.

Also, most developers tend to buy machines with the maximum RAM they can. I've got 4GB in my macbook pro and the 20 chrome tabs can't be taking up more than 500MB all together. Comparatively, Safari seems to take up a lot more memory than Chrome.

> Sometimes when I switch to a tab that has been idle for over a hour, I notice it takes chrome some time to render it again.

That sounds like paging in effect, which is decades old. Maybe you just notice it more now!

Virtual Memory consumption usually isn't worth paying attention to if you don't understand what's going on on a technical level, because it's meaningless for most purposes (each tab could be sharing 99% of that gig of address space, and that address space may never need to be mapped into real RAM, etc).

Flash Block and AdBlock go a long way.

Chrome's multiprocess architecture is brilliant on paper, but I've had more problems with it in practice than I care to list. Put simply: it's not a good idea to launch a separate process for each tab. If it was, nobody would use threads for anything and everyone would be happy.

This is what used to happen to Chrome on my MacBook when I had "only" 2GB of RAM:

1. Navigate to HN and click on 10 interesting stories + related comment threads.

2. Chrome tries to launch 20 processes at once. Processor usage goes through the roof and knocks several weather satellites out of their orbits.

3. The entire OS X UI freezes. I can't even Cmd+Tab to another application.

4. Some Chrome processes inexplicably crash (why?!). Nearly every other app gets swapped to disk.

5. Some old tabs get swapped to disk (which means switching to them later takes 3 to 5 seconds).

6. Processor usage becomes normal after 2 minutes. The OS becomes responsive again.

7. All my frustrated Cmd+Tabs and mouse clicks are finally registered and the UI does a halting, jitery dance as my inputs are de-queued and routed to several different apps.

8. After figuring out what buttons I accidentally clicked and in which apps, I can read HN!

Note: I know I've done a fair bit of Chrome-bashing on HN lately. If that bugs you, I apologize. It's just that I can't stand terribly engineered software grabbing a large share of the market. Chrome makes some interesting trade-offs re efficiency and the result is really not that bad. Chrome works fine for most non-geek, non-tab-happy people. For people who pretty much live in their browsers, though, Chrome is a terrible choice. Unless, of course, you have powerful machines. I believe Chrome's multiprocess model will be less of a bottleneck as processors evolve, but it's a pain in the ass on most contemporary machines.

This kind of analysis is useless without numbers and testing.

On the contrary, it's useful because it points the way to something that's worth putting effort into testing and number-gathering for.

Maybe. I wouldn't make any conclusions using it though.

If the user is quickly opening tabs, then the browser should probably use some QoS heuristic to queue or delay loading of tabs.

The Firefox "BarTab" extension does something like this:

https://addons.mozilla.org/en-us/firefox/addon/bartab/

As a fellow mac user: If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine. I say this as someone who compiles from source and runs server software on my mac almost every day. mogodb, apache, nodejs, mysql, tomcat is just the tip of the iceberg in the server department.

> If you are rebooting your Mac for reasons other then system upgrade, something is wrong with your machine

Indeed; that is the point of the article. =)

Or you have made the grave, grave mistake of installing Adobe products on your machine.

Except for those who rely on Boot Camp for gaming. These people have to reboot whenever they want to switch from work mode to game mode.

Maybe app users experience this. I use a Mac Mini for development/test as an alternate platform.

I have to reboot the dang thing every day or two. The development tools hang and screw up. The network drops and needs to be unplugged/plugged back in or rebooted. The debugger totally fails to breakpoint and only a reboot will fix it.

I alternate between banging my head on the wall, and white-hot fury at the thing. Fortunately I only occasionally have to verify the code still runs there, and don't have to live in that environment.

Reply on news.ycombinator.com