JVM garbage collection and a paging memory architecture

Question

In the recent 10 year when discussing java and/or garbage collection, the only performance penalty that I have not been able to defend is that garbage collection algorithms more or less breaks when running in a paged memory architecture, and parts of the heap is getting paged out.

Unix systems (and especially Linux) agressively pages out memory that has not been touched for a while, and while that is good for your average leaking c application, it kill javas perfomance in memory tight situations.

I know the best practice is to keep the max heap less than the physical memory. (Or you will see your application swap to death) but the idea - at least in the unix world, is that the memory could be better spent for filesystem caches etc.

My question is: Are there any paging (aware) garbage collecting algorithms?

Answer 1

I'm going to contend that this is not as big an issue as you think.

To make sure that we're describing the same thing: a complete collection requires the JVM to walk the object graph to identify every reachable object; the ones left over are garbage. While doing so, it will touch every page in the application heap, which will cause every page to be faulted into memory if it's been swapped out.

I think that's a non-concern for several reasons: First, because modern JVMs use generational collectors, and most objects never make their way out of the young generations, which are almost guaranteed to be in the resident set.

Second, because the objects that move out of the young generation still tend to be accessed frequently, which again means they should be in the resident set. This is a more tenuous argument, and there are in fact lots of cases where long-lived objects won't get touched except by the GC (one reason that I don't believe in memory-limited caches).

The third reason (and there may be more) is because the JVM (at least, the Sun JVM) uses a mark-sweep-compact collector. So after GC, the active objects in the heap occupy a smaller number of pages, again increasing the RSS. This, incidentally, is the main driver for Swing apps to explicitly call System.gc() when they're minimized: by compacting the heap, there's less to swap in when they get maximized again.

---

Also, recognize that heap fragmentation of C/C++ objects can get extreme, and young objects will be sprinkled amongst older, so the RSS has to be larger.