Hacker News new | past | comments | ask | show | jobs | submit login

No actual data, barely any technical discussion at all, mention of "the garbage collection algorithm" which most likely isn't even being used by most of the apps running, capped by a total cargo-cult solution... and this is #1 on the front page?

The post is (too) light on information, but I don't dismiss it immediately. Perry Metzger was very much involved with NetBSD (maybe he still is) as a developer. He might know a thing or two about memory management ;).

Metzger's post is much more subdued and interesting. IMO it would have made a much better submission. Link for the curious (it's linked from this article):


I still don't quite grasp it. He is talking about page outs, but how is disabling the dyn-pager helping with that? Shouldn't page outs only happen when RAM is full?

At my machine with 8 GB RAM and uptime of 4 days I have page outs of only 2 Megabyte. And page ins of 2 Gigabyte.

P.S. I subscribe to your blog! * starstruck

RAM serves (at least) two purposes: holding application data, and caching disk data. Sometimes it can be useful to swap application data out to disk to make more room for disk caching. Imagine if you have an app taking up a whole lot of memory that isn't actively using most of it, and another app reading a lot of data from the disk. In this case, you'll perform better if you swap out all that unused data, and use that RAM to cache disk access for the other app.

What he's saying is happening is that the OS is doing this too aggressively, and that it ends up swapping out data that's actually in use in favor of disk data which doesn't really need to be cached, which hurts performance.

By disabling the pager, you make it impossible to move application data to disk at all. This limits the amount of RAM available for disk caching, but if the OS really is caching too aggressively, that will ensure that it can never page out useful application data by mistake.

My experience mirrors yours, in that it really doesn't seem to be a problem on the computers I've used, but that's what he says he's seeing.

Glad you like the blog, but I'm just a regular guy. I put my pants on with a high speed pants installation robot just like everybody else.

Anecdotal data point (against the article): I have almost the same setup as this guy (2008 Mac Pro with 24GB and a 2011 MacBook Pro with 4GB), and even though I torture those machines with many hungry apps running concurrently, I haven't run into the same issues. Furthermore, I can't reproduce the high Inactive RAM count nor the high page-out activity, even after weeks of uptime.

Garbage collection does not have to mean GC as we know it from Java. It's not that the objects created by the app are garbage collected. The whole memory management in modern systems resembles a GC (it pretty much is a GC). Just instead of managing liveness of the objects, you manage the block mapping. Sometimes you have to write them back to the disk, sometimes you have no memory left and you have to swap them out...

That's pretty much the GC algorithm. There's nothing wrong with that mention.

When he says "the garbage collection algorithm may require that all of a program’s data be in physical RAM before collection can happen," it sure sounds like he's talking about in-app heap collection. Does "may require that all of a program's data be in physical RAM" really apply to the kernel level of memory management? It makes no sense to me when applied that way.

I don't see why this was downvoted. There are probably still many applications in the wild that use Objective-C 2 garbage collection. The garbage collector scans the stack and global memory for references, and recursively follows strong references to find out which objects are in the reachable set. This may touch a lot of memory pages that were paged out. So, even if the garbage collection algorithm does not require application to be in physical RAM, probably many pages will faulted to physical RAM as a part of garbage collection.

Yes, I agree. Way better than most HN articles.

Probably a lot of people hitting the up arrow to save the link to try out this evening. I plead guilty to doing that. I wish I'd read the comments first.

I do that too sometimes. Wtb separate save button.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact