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.
