Smashing baby!
"Imagine the day computers fix their own problems before you even know it." No, this isn't a line from one of Ray Kurzweil's masterpieces. I have been doing some reading lately on the state of Autonomic Computing and I like what I see. I suspect big corporate behemoths [we won't name names here to protect the guilty] are looking at this arena for the next technological bloodbath. I first heard of the SMASH (simple, many and self-healing) concept when Deep Blue kicked Kasparov's ass. Not a lot of information on the progress made since has been released widely into the public domain. But I for one will be following this trend.
I came across this item on the feature list for J2SE 1.5 (Tiger):
No more details. Nothing else! Now let's not kid ourselves by comparing this with Autonomic Computing, but surely if Solaris has had self-tuning capabilities for years now, is it such a big deal to get the Java Virtual Machine (JVM) to do it too? How many people seriously feel that the default heap size of 64MB is adequate for most computing? Well, Joe Public Developer doesn't go set the heap size unless forced to [ most times not even]. Why not follow the BEA Weblogic JRockit lead in implementing the ability for the virtual machine to expand or contract the Java heap during runtime. This would mean that users would no longer be required to fully understand the memory needs of their application system. Instead, they can trust the JVM's memory system to adjust the heap size based on application needs. Here's an excellent article by Eva Andreasson.
In addition to providing memory usage performance equal to manually tuned systems, a self-tuning mechanism can also dynamically detect changes in the application environment, and then take corrective measure. Didn't Einstein say "Everything should be as simple as possible and no more"? Well, this is simple. And it's about time!
I came across this item on the feature list for J2SE 1.5 (Tiger):
Java Heap Self Tuning
The option to request that the JVM self tune the size of the Java heap has been improved to consider both application performance and application footprint. You can specify performance goals for applications and the JVM will tune the size of the Java heap to meet those performance goals with the smallest application footprint consistent with those goals.
No more details. Nothing else! Now let's not kid ourselves by comparing this with Autonomic Computing, but surely if Solaris has had self-tuning capabilities for years now, is it such a big deal to get the Java Virtual Machine (JVM) to do it too? How many people seriously feel that the default heap size of 64MB is adequate for most computing? Well, Joe Public Developer doesn't go set the heap size unless forced to [ most times not even]. Why not follow the BEA Weblogic JRockit lead in implementing the ability for the virtual machine to expand or contract the Java heap during runtime. This would mean that users would no longer be required to fully understand the memory needs of their application system. Instead, they can trust the JVM's memory system to adjust the heap size based on application needs. Here's an excellent article by Eva Andreasson.
In addition to providing memory usage performance equal to manually tuned systems, a self-tuning mechanism can also dynamically detect changes in the application environment, and then take corrective measure. Didn't Einstein say "Everything should be as simple as possible and no more"? Well, this is simple. And it's about time!
0 Comments:
Post a Comment | Home | Inference: my personal blog