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.
Comments:

Post a Comment:
Comments are closed for this entry.
About

gbracha

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Feeds