How is Gilad Bracha like Herbert von Karajan?
This was originally an email I sent to the JavaPosse after listening to an episode of theirs which got me thinking about what I'd like to see from the JVM in the future. But I've decided to revise and extend those remarks here to help me clarify my thinking on the topic.
So here's what I meant by the title of this post:
A friend and I were once discussing the classic Deutsche Gramophone recording of von Karajan conducting the Berlin Philharmonic in Beethoven's Ninth. I said to my friend (parroting reviews that I had read) how great that music was. My friend replied: "I know that Herbert von Karajan knows more about the Ninth than I can ever hope to, but still... that's the most ponderously slow performance of that piece that I have ever heard".
I know that Gilad Bracha knows more about the inner workings of the JVM and the JLS than I can ever hope to, but still...
As little background: I attended Gilad's talk at JavaOne this year on supporting dynamic languages in the JVM. (You'll need to login as contentbuilder/doc789 when prompted if you follow that link).
Gilad has started a JSR which he anticpates will propose that a new instruction be added to the JVM to support dynamic invocation of methods, i.e. an instruction which won't require the heavy type checking that the current invoke* instructions do. The notion is that this will speed performance of other languages which target the JVM as a runtime environment but which, unlike Java, make use of dynamic typing. The goal and desired outcome seems quite reasonable and during the talk I found out things about the JVM that either I didn't know or had forgotten long ago. But, unlike most J1 sessions, the Q&A session which followed fascinated me almost as much as the talk.
The first questioner was Corky Cartwright. Full disclosure: I had spoken with Corky (whom I know, like and respect) prior to Gilad's talk and had agreed with him that getting tail calls supported in the JVM was of prime importance if functional languages were to be first class citizens in the Republic of Java. So when I saw Corky approach the microphone, I knew he was coming loaded for bear.
What followed was (for me anyway) the wonderful spectacle of two passionate professors engaging in a theological debate on the value of particular JVM features with each wanting their particular esoteric feature added. (Gilad's title at Sun after all is "Computational Theologist") . Basically, folks in attendance were getting a grad school seminar without paying tuition. It was wasted on most of the audience. Needless to say, I expect that it's Gilad's esoteric feature that will make the cut for Dolphin, while Corky's is viewed as being too complex.
After the presentation Gilad wrote a blog entry on being surprised that no one had brought up continuations as a desirable feature. That's the action that motivated me to write this blog entry. Basically, I'm arguing that invokedynamic, tail calls, and continuations should all get serious consideration for support in Dolphin, and that if Sun can't/won't do that for fear breaking the JVM, open sourcing Java would allow others to do it and see the effect.
First, you may want to review this discussion of continuations from the Lambda the Ultimate site. (LtU is one of my favorite sites). I think it says what needs to be said about continuations in the briefest manner:
A continuation *is* a closure - there's no difference, conceptually (there may be implementation-level differences, which essentially reflect that a continuation is a closure which has been created in a different way than most closures).
The things that tend to mess people up when thinking about continuations are (a) not fully understanding closures in the first place; (b) the behavior of what Scheme calls call/cc, which wraps up the "current continuation" as a closure; and (c) the idea that functions don't have to return to the place that they're called from, which is fundamental to the notion of continuation.
So, working with that definition, lets talk about Gilad's two posts a bit more. The example of usage of continuations that Gilad gives (and dismisses) in his blog entry is the easiest to understand example for all 10,000 of the Java programmers out there who have written a web framework (and had it discussed on the JavaPosse) . It is NOT the appropriate use case for deciding if continuation support should go into the JVM, though. More illuminating examples for that decision are ones that Gilad doesn't respond to, but which arise in the comments of his blog posts. These are 1) support for languages other than Java in the JVM and 2) grid computing.
In this longish post on JRuby at the Headius blog site, I found the following to be quite revealing on the topic of language support:
In JRuby's case, a major missing piece was the inability to longjmp, C's function for leaping from one call stack to another. longjmp is heavily used (understatement!) in Ruby for everything from threading to continuations to exception handling. Missing longjmp in Java presents a very large hole when porting Ruby C. Many creative attempts to mimic longjmp were therefore created: exception-based flow control allowed loop keywords like 'next' to throw control back to a higher-level loop construct; a recursive evaluator repeatedly called itself for new AST nodes, ever-deepening the stack but always keeping lower nodes within the context of higher ones; exception-based "return sleds" allowed returns to bubble their results back up to the appropriate recipient; and on and on. Many of these approaches were extremely novel, worthy of their own papers and accolades. Indeed, several of them have shown up in academic papers and PhD theses in some form or another.
This (and some other discussion in that post) implies that dynamic languages which implement continuations (or just closures) have to do their JVM implemenation in a pretty lame manner - they end up keeping the stack for the language implementation in the JVM heap so that they can do the necessary manipulation of the stack that the language demands. In effect, they have to manipulate their flow control structures in a manner that reminds me of someone doing all of their Java method invocations via reflection.
In JRuby's case, they end up sort of simulating the Ruby VM on the Java VM, it seems. This has to damage Java interoperability and the language's performance simultaneously and it severely complicates the design.
If Sun really values having other languages on the JVM, the two killer features that need direct JVM support would seem (to me) to be continuations and tail calls. Get those right and Lisp, Scheme, Ruby, Scala and others can be supported with their full native performance and, I predict, Groovy would get way faster. This sort of "foreign" language support is something I bet we won't see happening in .NET anytime soon, providing a clear differentiating feature for Java.
The second example that Gilad fails to take into account is the one that's really near and dear to my heart - grid computing with Jini.
In the kind of compute grids that spark my interest, what you really want to do is create a closure and dispatch it, along with a set of data to curry it, many times to a large number of computers, each of which binds the received data, then invokes the closure and puts the result of the closure evaluation somewhere where it can be found later. Think about it, that's asking for a closure which can be saved and executed elsewhere and which doesn't perform a synchronous return to the caller, i.e. it's asking for a continuation as defined above.
The fascinating thing about this model of a compute grid, when compared to models like MPI, WebServices and even JXTA, is that it allows your code to be mobile around the grid - a feature which, when run on Windows, is, unfortunately, called a virus. This, I'm betting, is why you don't see a Jini-like thing on Windows - anyone who suggests mobile code in Redmond is guarenteed to be hooted down as an advocate of allowing SoBig.F to run loose around the net forever. (But.... it could be another differentiating feature for Java if Sun ever really grokked what Jini is).
So... doing continuations in a secure manner requires one to be VERY careful. Unfortunately, being careful in the current JVM also requires an enormous number of special tricks - tricks which could be obviated, I suspect, if the JVM had first class support of closures and continuations without breaking the Java security model.
The current best tricks, IMHO, to use in support of this model are called - wait for it - Jini and JavaSpaces. Jini/JavaSpaces allows one to use RMI, or rather, JERI which should have been RMI 2.0, (see JSR-78 and JSR-76 ) with cryptographically strong codebase annotations to create a sort of light weight closure/continuation.
Rereading the gobbledygook that is that last sentence should tell you everything you need to know about why Jini hasn't stormed the world. It's just damned hard to understand, much less implement, secure models of mobile code. The fact remains nonetheless, that it is the current best way to do a compute grid. Look at the combination of the computeserver project and netbeans, and I think you glimpse part of the future of compute grids. But I am somewhat partisan, as one can probably tell from my latest JavaOne presentation. (You'll need to login as contentbuilder/doc789 when prompted if you follow that link)
So I would like to see Gilad von Karajan and the rest of the JVM team at Sun quit being so ponderously slow to introduce continuations (and tail calls and invokedynamic) and make life easier for groovy, ruby, lisp and Jini. But I ain't holding my breath..
Anyway, my fingers are now tired...
So here's what I meant by the title of this post:
A friend and I were once discussing the classic Deutsche Gramophone recording of von Karajan conducting the Berlin Philharmonic in Beethoven's Ninth. I said to my friend (parroting reviews that I had read) how great that music was. My friend replied: "I know that Herbert von Karajan knows more about the Ninth than I can ever hope to, but still... that's the most ponderously slow performance of that piece that I have ever heard".
I know that Gilad Bracha knows more about the inner workings of the JVM and the JLS than I can ever hope to, but still...
As little background: I attended Gilad's talk at JavaOne this year on supporting dynamic languages in the JVM. (You'll need to login as contentbuilder/doc789 when prompted if you follow that link).
Gilad has started a JSR which he anticpates will propose that a new instruction be added to the JVM to support dynamic invocation of methods, i.e. an instruction which won't require the heavy type checking that the current invoke* instructions do. The notion is that this will speed performance of other languages which target the JVM as a runtime environment but which, unlike Java, make use of dynamic typing. The goal and desired outcome seems quite reasonable and during the talk I found out things about the JVM that either I didn't know or had forgotten long ago. But, unlike most J1 sessions, the Q&A session which followed fascinated me almost as much as the talk.
The first questioner was Corky Cartwright. Full disclosure: I had spoken with Corky (whom I know, like and respect) prior to Gilad's talk and had agreed with him that getting tail calls supported in the JVM was of prime importance if functional languages were to be first class citizens in the Republic of Java. So when I saw Corky approach the microphone, I knew he was coming loaded for bear.
What followed was (for me anyway) the wonderful spectacle of two passionate professors engaging in a theological debate on the value of particular JVM features with each wanting their particular esoteric feature added. (Gilad's title at Sun after all is "Computational Theologist") . Basically, folks in attendance were getting a grad school seminar without paying tuition. It was wasted on most of the audience. Needless to say, I expect that it's Gilad's esoteric feature that will make the cut for Dolphin, while Corky's is viewed as being too complex.
After the presentation Gilad wrote a blog entry on being surprised that no one had brought up continuations as a desirable feature. That's the action that motivated me to write this blog entry. Basically, I'm arguing that invokedynamic, tail calls, and continuations should all get serious consideration for support in Dolphin, and that if Sun can't/won't do that for fear breaking the JVM, open sourcing Java would allow others to do it and see the effect.
First, you may want to review this discussion of continuations from the Lambda the Ultimate site. (LtU is one of my favorite sites). I think it says what needs to be said about continuations in the briefest manner:
A continuation *is* a closure - there's no difference, conceptually (there may be implementation-level differences, which essentially reflect that a continuation is a closure which has been created in a different way than most closures).
The things that tend to mess people up when thinking about continuations are (a) not fully understanding closures in the first place; (b) the behavior of what Scheme calls call/cc, which wraps up the "current continuation" as a closure; and (c) the idea that functions don't have to return to the place that they're called from, which is fundamental to the notion of continuation.
So, working with that definition, lets talk about Gilad's two posts a bit more. The example of usage of continuations that Gilad gives (and dismisses) in his blog entry is the easiest to understand example for all 10,000 of the Java programmers out there who have written a web framework (and had it discussed on the JavaPosse) . It is NOT the appropriate use case for deciding if continuation support should go into the JVM, though. More illuminating examples for that decision are ones that Gilad doesn't respond to, but which arise in the comments of his blog posts. These are 1) support for languages other than Java in the JVM and 2) grid computing.
In this longish post on JRuby at the Headius blog site, I found the following to be quite revealing on the topic of language support:
In JRuby's case, a major missing piece was the inability to longjmp, C's function for leaping from one call stack to another. longjmp is heavily used (understatement!) in Ruby for everything from threading to continuations to exception handling. Missing longjmp in Java presents a very large hole when porting Ruby C. Many creative attempts to mimic longjmp were therefore created: exception-based flow control allowed loop keywords like 'next' to throw control back to a higher-level loop construct; a recursive evaluator repeatedly called itself for new AST nodes, ever-deepening the stack but always keeping lower nodes within the context of higher ones; exception-based "return sleds" allowed returns to bubble their results back up to the appropriate recipient; and on and on. Many of these approaches were extremely novel, worthy of their own papers and accolades. Indeed, several of them have shown up in academic papers and PhD theses in some form or another.
This (and some other discussion in that post) implies that dynamic languages which implement continuations (or just closures) have to do their JVM implemenation in a pretty lame manner - they end up keeping the stack for the language implementation in the JVM heap so that they can do the necessary manipulation of the stack that the language demands. In effect, they have to manipulate their flow control structures in a manner that reminds me of someone doing all of their Java method invocations via reflection.
In JRuby's case, they end up sort of simulating the Ruby VM on the Java VM, it seems. This has to damage Java interoperability and the language's performance simultaneously and it severely complicates the design.
If Sun really values having other languages on the JVM, the two killer features that need direct JVM support would seem (to me) to be continuations and tail calls. Get those right and Lisp, Scheme, Ruby, Scala and others can be supported with their full native performance and, I predict, Groovy would get way faster. This sort of "foreign" language support is something I bet we won't see happening in .NET anytime soon, providing a clear differentiating feature for Java.
The second example that Gilad fails to take into account is the one that's really near and dear to my heart - grid computing with Jini.
In the kind of compute grids that spark my interest, what you really want to do is create a closure and dispatch it, along with a set of data to curry it, many times to a large number of computers, each of which binds the received data, then invokes the closure and puts the result of the closure evaluation somewhere where it can be found later. Think about it, that's asking for a closure which can be saved and executed elsewhere and which doesn't perform a synchronous return to the caller, i.e. it's asking for a continuation as defined above.
The fascinating thing about this model of a compute grid, when compared to models like MPI, WebServices and even JXTA, is that it allows your code to be mobile around the grid - a feature which, when run on Windows, is, unfortunately, called a virus. This, I'm betting, is why you don't see a Jini-like thing on Windows - anyone who suggests mobile code in Redmond is guarenteed to be hooted down as an advocate of allowing SoBig.F to run loose around the net forever. (But.... it could be another differentiating feature for Java if Sun ever really grokked what Jini is).
So... doing continuations in a secure manner requires one to be VERY careful. Unfortunately, being careful in the current JVM also requires an enormous number of special tricks - tricks which could be obviated, I suspect, if the JVM had first class support of closures and continuations without breaking the Java security model.
The current best tricks, IMHO, to use in support of this model are called - wait for it - Jini and JavaSpaces. Jini/JavaSpaces allows one to use RMI, or rather, JERI which should have been RMI 2.0, (see JSR-78 and JSR-76 ) with cryptographically strong codebase annotations to create a sort of light weight closure/continuation.
Rereading the gobbledygook that is that last sentence should tell you everything you need to know about why Jini hasn't stormed the world. It's just damned hard to understand, much less implement, secure models of mobile code. The fact remains nonetheless, that it is the current best way to do a compute grid. Look at the combination of the computeserver project and netbeans, and I think you glimpse part of the future of compute grids. But I am somewhat partisan, as one can probably tell from my latest JavaOne presentation. (You'll need to login as contentbuilder/doc789 when prompted if you follow that link)
So I would like to see Gilad von Karajan and the rest of the JVM team at Sun quit being so ponderously slow to introduce continuations (and tail calls and invokedynamic) and make life easier for groovy, ruby, lisp and Jini. But I ain't holding my breath..
Anyway, my fingers are now tired...
posted by E and J's Film Crew at 5:33 AM
3 Comments:
Try following your links. Several of them aren't available to the general public.
Yeah, the JavaOne presentations seem to be the problem... I'll see if I can fix it..
ok, if you follow the links to the presentations, you need to login as contentbuilder/doc789 to download the pdf. Since that's a public ID I don't feel bad about giving it out..
Post a Comment
<< Home