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!
It seems to me that the importance of garbage collection in Java (and other garbage collected languages) is disproportional to the explanations given about it. While there would be millions of articles when you look for JavaFX examples, there would be only a couple if you tried to search about the “Parallel Compacting Collector†mentioned in Sun’s memory management whitepaper.
Since I wanted to understand better how the garbage collection is currently implemented in the Java VM and to see what’s ahead, I’ve scourged the internet a bit and found many interesting articles and slides. With the searches, it became like the old saying: there is a lot of stuff you don’t know, but there’s even more stuff you don’t even know you don’t know. This post is my summary of what I’ve found, but this is just the way I understand the explained material in publications and whitepapers; if I’m wrong somewhere, please do correct me.
Liked Chaotic Java? It's free! But maybe you can