JSR292 and Hotswapping
JSR292 is now officially underway, chartered to extend JVM support for dynamically typed languages. We’ll define the new invokedynamic bytecode and explore what else we can do to encourage efficient implementations of such languages. High on the list of extra stuff is hotswapping.
Hotswapping means the ability to change code on the fly, while it is running. Ideally, anything can be changed - methods can be added, removed or modified, fields and be added or dropped, names of types can be changed and their superclasses and superinterfaces can be altered.
Now before you get all excited, I need to be very clear: we are not making any promises with respect to hotswapping. Full hotswapping support in a system with mandatory static typing remains an active research topic. We really don’t know how far we can go.
This reluctance to commit doesn’t stem from a lack of support for hotswapping, or a lack of appreciation of its value. As an old Smalltalker, I know what we’re missing here. Once you’ve used a system with these dynamic capabilities, you’re hooked for life.
I’ve been agitating for hotswapping support in the JVM since I started working for Sun in 1997. Currently, JVMTI provides limited hotswapping support in some JVMs. That support has its roots in a Sun Labs project that Randy Smith and I helped start back in the late 90s. Misha Dmitriev did all the work on that project, and then helped Janet Koenig’s serviceability team (Robert Field, Jim Holmlund) transfer it to production use.
However, it’s been up to vendors to decide if and how much to support, and nobody support anything close to full hotswapping. Fortunately, the culture is changing, and many more people have started to grasp what APLers, Lispers and Smalltakers have known for decades: hotswapping is incredibly powerful and useful. We owe this change in perception largely to the current crop of scripting languages, which we seek to support in JSR292.
The goal now is to see how much hotswapping can be done for the platform as a whole, and if we can’t (as I suspect) deliver full hotswapping, whether we can at least support full hotswapping for dynamically typed languages, where the issues are simpler. Whatever support we come up with should be a guaranteed part of the JRE, so developers can rely on it everywhere.
If we can get both invokedynamic and full hotswapping for dynamically typed languages working, implementations of languages like Python or Ruby could use the JVM object model directly, and really take advantage of the great performance of JVMs. That’s the holy grail of JSR292. I certainly won’t promise we’ll get all the way. I’ve seen how hard it is to turn ideas like this into a reality for the Java community. There are technical problems, resource problems, political problems .... Still, we’re about to get started (still forming the expert group) so wish us luck.
Posted at 03:07PM Mar 17, 2006 by gbracha in Java | Comments[8]
Having written a toy-implementation of Scheme on JVM, I can certainly appreciate invokedynamic, but that's really just half of the story: continuations were the real problem.
Since I wanted to support full continuations, I ended up implementing my own stack, which obviously killed performance. Furthermore, while I could call Java objects and implement Java interfaces so Java code could call back to Scheme, the continuations wouldn't work when there was Java code on the stack between the continuation point and current point of execution.
I understand that having support for continuations on JVM could break a lot of existing code (e.g. what are semantics of try..finally when continuations are present?), but do you think that JVM will support them at some point? After all, Ruby supports continuations and invokedynamic is not going to help that much if Java implementation of Ruby has to perform its own stack management.
But anyway, great to hear about your efforts on JSR292! I guess that even an unsafe hotswapping could offer a a great productivity boost for development: if you manage to totally hose the application with hotswap, you can always restart it.
Posted by Juha Komulainen on March 18, 2006 at 03:34 AM PST #
Posted by Patrick Lightbody on March 18, 2006 at 12:10 PM PST #
Posted by Dennis Bekkering on March 18, 2006 at 02:39 PM PST #
Posted by Guillaume Laforge on March 19, 2006 at 03:16 AM PST #
Posted by Hummus and Magnets on March 19, 2006 at 05:21 AM PST #
Posted by Geert Bevin on March 19, 2006 at 11:02 PM PST #
Posted by eimers on March 20, 2006 at 11:37 PM PST #
1) Continuations. That's a tall order. I'm happy that after all these years, a meaningful use of continuations has been found - continuation based web servers. However, they raise serious issues of both performance and security. I guess I'd need a separate post to discuss all that. I don't expect JVMs to offer support for that
How big a problem is that? It depends on your perspective. I don't think that competing with Ruby's current performance is going to be an issue on a JVM, even if you maintain your own stack.
2) Geert and Patrick have commented here and in other forums on the need for hotswapping, and seem displeased with the rate of progress and skeptical of the potential for further progress. I too am displeased with the progress on this and many other fronts. Time will tell if we achieve something useful, or if it really will be "too little too late".
I do want to emphasize that the problems are harder than most people realize.
Also, the focus in JSR 292 is supporting scripting languages. If it turns out that we can support them without providing a solution for ordinary Java class files, we may go with that. That may not help people like Patrick and Geert. Sorry.
3) Why introduce a new name (no doubt in reference to my earlier posting about gratuitously new terminology)? Because there is not a generally accepted, concise name for this stuff. 'Dynamic software updating' isn't specific enough. It sounds like the sort of thing that happens with OS updates all the time - which often requires a reboot. 'Reflective program change' is more accurate, but it is a mouthful.'Self modifying code' is the oldest one, but long, and has all the wrong connotations. 'On-the fly software update' might work, but it is still too long. So I think there is a genuine need for a new term.
Posted by Gilad Bracha on March 21, 2006 at 01:30 PM PST #