|
|
|
|
Back to newsletter 182 contents
I'm seeing some interest in sofware transactional memory for Java systems as a potential solution to a lot high level concurrency problems. What I rarely see is any awareness that we've had software transactional memory in Java for 20 years in at least one system - the GemStone one. This was a fully distributed transactional system capable of executing Java on both the client-side and server-side. I had the opportunity to use it, and it worked well. But over time the server-side Java support was discontinued, from what I presume was lack of sufficient commercial interest. It still supports client-side Java execution in a software transactional distributed system. Perhaps it was ahead of its time or a victim of the 2000 dot bomb, but I wonder whether its perhaps that the effort needed to maintain software transactional memory alongside all the other changes continually happening in Java is just too high. Regardless, I wouldn't wait for sofware transactional memory in your JVM to become available soon enough to solve any of your current concurrency problems.
Now on to our usual links to tools, articles, news, talks and as ever, all the extracted tips from all of this month's referenced articles. Amongst those, Peter Lawrey's Low Latency talk touched on the consistent performance tuner's problem, that people want it "faster", and even "as fast as possible" but there is no thought about the tradeoff - how much that will cost or how much time needs to be applied. There is always some target that is "fast enough because it's not worth spending more time/money to make it faster and we can live with this". Performance tuning should always start by deciding on that target, or you'll end up wasting time and money.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 182 contents
