After the two posts about garbage collection (basic and advanced) I started receiving questions regarding the works of the GC, and tips on how to use it properly. This post will be devoted to that subject, with some of the questions asked brought into highlight and answered using a lot of information coming from a great presentation Sun gave on the subject and with some knowledge acquired from the previous posts’ research material.
This post is all about data flow in the “New I/O” framework. The data flow mechanism in NIO is essentially different from the “old” IO. There are no decorators to data, and the entire framework revolves around getting one thing done, and done really well: transferring data from an external source into the application or vice versa. In the last post I’ve described the buffers and put some emphasis on a couple of them. In this one, I’ll discuss the channels, which are the equivalents of the streams in the old IO, and the selector idea, which is taken from low-level languages such as C and brought into Java to boost performance.
In the last post, I’ve been talking about the basics of garbage collection and the generational garbage collector. While the generational garbage collector brought huge performance benefits by getting the large, old generation memory area to be infrequently visited by the collector, it still wasn’t enough for the new era of faster processors and memory sizes which spawned larger applications with multiple threads running concurrently, creating loads of garbage. The original generational collector was single threaded, and was called the serial collector. A parallel collector was required, and since the young and old generation memory spaces are different in the way the objects residing in them are used, so are the collectors implemented for them.
Since explaining multi-threaded implementations is difficult, and more-so when it’s with the topic of garbage collection, I’ve used illustrations that depict the state of a one or two threads at a time; in reality, the amount of threads running is equal to the number of processors the machine has, which can easily be a two-digit number. I hope the explanations are clear enough, and as always questions are welcomed!
Chaotic Java is Digg proof thanks to caching by WP Super Cache!
