Java Garbage Collection, Monitoring, and Tuning

Editor's Notes

• #4: Lets look at some of the changes and new features in the Java Virtual Machine
• #5: Why are we here? In C/C++ you do the memory management. You make the calls to malloc() and the calls to free(). Forget the calls to free() and you're leaking memory.. And, of course, you don't use the memory once it's been freed. And, you free memory exactly once.
• #6: In a nutshell, a GC ... Our garbage collectors are generational, meaning we divide the heap into two regions and don't have to always collect the entire heap. When we only collect one of the regions we call it a minor collection. Minor collections are typically much faster than major collections and often collect enough memory so as to delay the more expensive major collection.
• #7: So garbage collection is your friend. The source of some ugly bugs has removed. You spend more time on the interesting stuff. You don't have to think about memory management as much in your design. But there are some costs. Your going to have pauses in the application execution when a GC occurs. You don't know when a GC is going to occur and don't know how long it is going to take. Finalization depends on GC's. User's of you programs may want to choose among the different collectors to achieve a particular performance (e.g., better throughput or shorter pause times). Some tuning may be required.
• #8: When Sun did the original work on the HotSpot development they did a lot of analysis of applications and how they behaved with respect to the VM (as we saw in the earlier slide showing the pie charts). Part of this analysis revealed some interesting data about the typical lifetime of objects. As we see here most objects are very short lived. Knowing this has a significant impact on the choice of algorithms used for GC and the design of the heap layout.
• #9: Java does the memory management for you. The JVM finds the data that is still in use by the program. This data is referred to a reachable. Anything else is collected as garbage. You never have the equivalent of a dangling pointer. If you have a reference to data, it's there, it has not been collected as garbage. No free's obviously means no double frees. In principle you cannot have a true memory leak but there are things that you can do that are as bad in practice. Basically, you have a reference to data that is never going to be used again. This is more accurately described as unintential object retention but is often just called a memory leak. If your program has such a memory leak, you'll ...
• #10: When we first allocate object, we treat it as Eden space it is stack based allocation, we allocation chunk of memory where we maintain a pointer to the beginning of it, and move the pointer along, putting the object in that space. No search for free list, very efficient. When Eden space is full, we do GC on this, we stamp the valid objects, if the object is valid we copy it from Eden to semi spaces “from space”, GC pause is directly proportional to total size of live objects, so this done very efficiently, ... do a copy into then “to space”, that's what we call Tenuring by doing this we are maturing objects. Most of the objects in Eden space are very young and short lived, and in 2 semi spaces are a little bit long lived. We actually tune how long the objects are going to stay in that young generation. We then copy all those valid objects from semi space to old generation. Again use simple stack based allocation to allocate the objects. For old generation, we have a different GC algorithm, may be incremental, mark-sweep compact, we have choices what we do that. Also another space is called permanent space, it's used for classes information. You don't allocate or put things in those objects, the VM will actually use it for classes information. Default sizes: 64 KB for semi space is not very large, so we will talk how you can change that. Survivor ration is eden and 2 semi spaces, changing the value is going to impact the performance ??? Young generation fits for copy collect while old is more for the others
• #11: The point here is to make it so that the garbage collection proces is not as disruptive to your application. So the garbage collector works at the same time as your application , short stop do a little work then go back, so that you dont see one long pause. Has some overhead that lowers throughput a little. The young generatons collections are short already so there is no need to put that extra overhead on the young generation We only do incremental of the old generation
• #13: Before going further let me tell you about memory management on a modern Java platform. Allocation is definitely not slow. It was slow in ... Garbage collection has gotten much, much faster than in the early days but a collection does still happen all at the same time so it's noticeable. We don't use reference counting. That's notable because reference counting does slow down the execution of the program. Because early performance was an issue, there's some lingering advice on how to get better performance. Much of that is out dated. And some of the bad advice actually leads to memory leaks.
• #14: Memory allocation is fast , really cheap You don't have to keep track of the remembered set, tracking pointers from old to young, does not have to be done for younger objects. Short lived objects can be reclaimed very fast
• #19: Okay, so we don't have true memory leak, right? But we can hold onto objects that are never going to be used again. You can find plenty of examples of such objects ... In the best case such objects cause more work for the garbage collector. In the worst case you can get an out-of-memory exception because of them. In the next few slides we'll look at three examples of these types of memory leaks.
• #22: In this example an object that stays around longer than it is needed. “ byteArray” is part of “LeakyChecksum” so will live as long as the LeakyChecksum object live. It is. however only. needed during the invocation of geFileChecksum. Now maybe this is ok, but realize that byteArray is going to be as large as the largest file ever read, the garbage collector has to look at it at each collection, and the space would be used more profitably for the allocation of other objects.
• #28: This third example of a memory leak is less easy to workaround. You have an object and you want to associate some information with that object but you cannot put the information in the object itself. In this case you have a socket and want to associate a user id with the socket. A natural solution is to create a map between the socket and the user id as here in the SocketManager. Here the example uses a HashMap w
• #29: Here's the example with a fix using the WeakHasMap. WeakHashMap give you the direct connection between the key and the metadata that you need here. Don't replace all your HashMaps with WeakHashMaps. Reference processing does cost during GC and it would be a waste to always use it.
• #30: Have a explicit reason if you are going to null a reference. Mostly it doesn't help. Occasionally it's exactly the wrong thing to do. A System.gc() will trigger an full collections. In tuning the GC we often try hard to minimize full collections. Understand why you are doing System.gc(). Allocation is fast so just use it. Object pooling has costs in terms of filling up the heap so, again, understand what you are doing.
• #32: You are not guaranteed that a finalizer will ever run so, if you use them, you need design for that contigency. Regarding finalization we mostly hear from people who are trying to manage a scarce native resource which is probably the wrong thing to do. Try to use finally block first. That's the simplest and most deterministic.
• #33: Lets look at some of the changes and new features in the Java Virtual Machine
• #34: The big goal of “smart tuning” sometimes referred to as ergonomics, was good out-of-the-box performance for server applications. From the early days the VM has been tuned to run well with desktop applications because the overwelling majority of executions were for desktop applications. That hurts when customers run benchmarks for large server applications because that is often done without tuning the VM. In tiger we look at the machine we're running on and try to make some smarter choices. We've also added a simplified way of tuning garbage collection.
• #36: This slide shows the effects of tuning on 4 benchmarks. This is without “Smart tuning”. Bigger is better. The 1.4.2 untuned VM is in blue and the hand tuned tiger VM is in red. Tuning can make a big difference. Business logic – specjbb2000 Bytecodes – specjvm98 i/o – jetstream Scientific – scimark2
• #37: This is tiger tuned versus out-of-the-box performance on the same benchmarks. The blue is the out-of-the-box performance for tiger and the red again is the hand tuned tiger VM. Smart tuning has made tiger out-of-the-box performance is much closer to the tuned performance.
• #38: Lets look at some of the changes and new features in the Java Virtual Machine
• #45: Lets look at some of the changes and new features in the Java Virtual Machine