> > > 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 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. 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. 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 javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
