Hi Dick, I'm happy to hear you say that immutability isn't a silver bullet. But the message is still coming in strong that it is and as I mentioned before, the problem isn't with GC. As you've mentioned, the cost of gc'ing an object in eden is almost nothing. It's never visited, it's never copied and in fact, they are never collected, the memory they occupy is placed back on the free list in one pointer reset. In fact, there really isn't a free list in any of the young gen memory pools. So, thats not the problem as GC for very short lived objects is cheap. The problem is, these short lived objects *still* need to be written out to RAM and that is the problem. Object lifecycle in the VM has gotten so good that it is not possible to have a collector running at close to 100% efficiency yet have memory management be the main bottleneck in your application and this is due to write bandwidth pressure. My lunch time argument with Rich was not in disagreement with is POV or PIT structures that he sets up in Clojure, it's the immutability that he uses to create these large data structures. Ultimately, (unless hardware changes significantly) these structures will limit scalability. My point was backed up with Cliff's talk at the summit on how modern hardware works. My later conversations with Rich indicates that he did not fall off of the immutability bandwagon (sorry didn't want to suggest something that strongly) but he has recognized that he needs to do more if performance is an issue.
As for your DB example.... it's a perfect place to punt a heavy transactional engine and just by doing that you will see a huge saving (or performance boost). This is something that I recommend people do quite often. In fact it was a recommendation that I made just last week to a client that clearly had mostly read occasionally write. In this case the occasional write can be managed quite easily without synchronization or immutability. In fact, it can be managed very easily with an AtomicReference. The write is not that complex using AtomicReference. It did require a wee bit of thought but in the end, it's not that more complex than "simply" making the structure immutable. I suggest that everyone look at Cliff's excellent work in this area. If what you're suggesting is that most normal programmers wouldn't be able to have created Cliff's or Doug's work then we are in total agreement. But if you're suggesting that we can't understand or expand on the ideas after understanding then.... I often present Cliff's work (Lock free) or Doug's work (wait free) and I offer a few examples of were one can provide some useful extensions. Again, I'm not against immutability, it just seems that we've all picked up on that sound bite and have forgotten all of the other colors that make the world interesting. Regards, Kirk On Jun 20, 2011, at 4:00 PM, Dick Wall wrote: > Hi Kirk > > On Jun 17, 5:58 am, Kirk <[email protected]> wrote: >>> As for immutable objects, surely at this stage of the game their value >>> is not in dispute (is it, really?). I would not trust a multi-threaded >>> system with shared mutable state no matter how good I thought I was >>> with synchronizing threads. If Brian Goetz, Doug Lea and Guy Steele >>> don't trust themselves, then I would say the rest of us are foolish to >>> think we can do any better. I have also noticed no performance loss >>> from the number of short lived immutable, small objects created - the >>> garbage collector works more quickly on young objects, and performance >>> of running code is one concern I have not had at all with Scala. >> >> Hi Dick, >> >> I am on the (not so short) list of those that don't believe that >> immutability is the cure all for concurrency. > > I also am on that list - there is no cure all. That said, concurrency > with immutability is a hell of a lot easier than if that particular > tool is not even in the toolbox. Constructs like concurrent hash map, > parallel arrays and all the other things you mention are also critical > tools. What I meant to convey is that all of these concurrency gurus > said the same thing when I talked to them - the worst thing you can > possibly do is to try and use synchronized threads yourself to solve > mutable state problems. > > > I counter your Brian, Doug and Guy with Cliff Click. And, I'm not sure > that Brian is completely on the list of immutability. Doug clearly has > a number of mutable thread safe fully concurrent data structures at > least one of which is lock-less and wait-free! RIch Hickey is another > that you can take off of the list that immutability is the cure to all > that is evil about concurrency. I softened him up in Aarhus and Cliff > finished him off at the Java Language Summit. >> > > Clojure is entirely built around the STM model of concurrency where > any particular thread/object has a completely fixed view of an > immutable datastructure, one that can only change in a transaction, > and out the other end comes another immutable datastructure. I think > Rich is one of the biggest proponents of immutable state - far more so > than I am, and I have not seen anyone convince him otherwise > (certainly not at the JVM language summit either when I talked to > him :-) ). > > Doug's libraries are brilliant, and are a great way to achieve good > concurrency, but certainly parallel arrays, for example, go hand in > hand with small, short lived immutable value objects and functions > that work on them. To go further, those libraries go really well with > a language like Scala that has first class functions too. > > And Brian Goetz is the one who started me on this path without the > performance fears by telling me that small, immutable, short-lived > objects are far more easily and quickly garbage collected by the JVM, > and it makes sense if they don't get promoted through the first GC > cycle after their creation. > >> So, what is wrong with immutability. On the surface, nothing. And if used >> judiciously, I'm ok with using it. However, used liberally and you will end >> up with a system that will run slowly for no apparent reason. The no >> apparent reason is because the measurement that you need to consider is CPU >> write channel bandwidth to memory. This is a measure that very very few >> people consider but it is a measure that is becoming increasingly important. >> A few years ago I would have never seen an application who's performance >> would have been effected by the capacity of the CPU to write data to memory >> but since then, I have started running into a couple of applications that >> are putting enough pressure on that part of the hardware that it has had a >> significant impact on performance. Immutability only increases the pressure >> on this up and coming bottleneck. This is also a testament to the much >> improved performance of the JVM >> >> Two factors why the situation isn't going to get better any time soon. >> >> Your comments on GC are completely correct, catching a short lived objects >> (those caught in Eden) is almost a 0 cost operation. That said, (dead) >> objects will still pushed from the CPU to memory. CPU's are getting faster >> and memory at a rate of about 8% per year. That means that CPU starvation is >> going to increasingly be a bigger problem than it already is. The ability of >> the CPU to generate data is already outstripping the ability to get it out >> of the CPU and that is only going to get worse. According to Azul studies, >> 50% of the memory bandwidth is being consumed by writing *dead* objects to >> memory. There is a hardware solution to this problem but it is specific to >> Java and consequently is unlikely to show up in an Intel or AMD CPU any time >> soon. Again, Immutability will only increase the pressure. >> >> I believe you when you say that you don't notice the effects of immutability >> on your Scala application. I've had the pleasure of performance tuning a >> Scala app and have also sat with Bill (Venners) and Martin (Odersky) >> measuring and diagnosing performance problems in Bill's build tool and the >> compiler. In all cases I found plenty of other issues that would most likely >> prevent a Scala application from being able to put so much pressure. >> >> I don't want to take anything away from Scala, I think it's a great language >> that offers some great features and there are definitely benefits to using >> it. But, instead of relying immutability exclusively we need to also >> consider alternate styles of concurrency like those suggested by Doug's >> WorkTransferQueue, Cliff's NonBlockingConcurrentHashMap and in those coding >> styles, my almost FIFOQueue. The later two rely on state machines to handle >> transitions. I would never claim to be clever enough to come up with a >> NonBlockingConcurrentHashMap but I do understand how it works and why >> certain decisions were made a key points in the implementation. Ok, maybe >> this is a wee bit more complicated than straight up immutability but then we >> don't have to be geniuses like Doug, Cliff, Brian, Rich, Guy.... we just >> need to learn how to ride on the coat sleeves of these guys. >> > > I agree - and I use all of these libraries. My first stop is still > small, immutable, short-lived objects though, after that, Guava's > mapmaker is my next port of call typically, or the parallel > collections if I can use them. I haven't written a synchronized into > my code for a couple of years now, nor have I needed to. > > To get back to the original point though, for the database work we do > (write once, very rarely modify, heavily read) immutable objects read > into memory and disconnected from the database have improved > performance in our use case enormously. It's an easy win. > > Dick > >> Regards, >> Kirk > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
