Friday Jun 24, 2011

Feynman's inbox

Here is Richard Feynman writing on the ease of criticizing theories, and the difficulty of forming them:

The problem is not just to say something might be wrong, but to replace it by something — and that is not so easy. As soon as any really definite idea is substituted it becomes almost immediately apparent that it does not work.

The second difficulty is that there is an infinite number of possibilities of these simple types. It is something like this. You are sitting working very hard, you have worked for a long time trying to open a safe. Then some Joe comes along who knows nothing about what you are doing, except that you are trying to open the safe. He says ‘Why don’t you try the combination 10:20:30?’ Because you are busy, you have tried a lot of things, maybe you have already tried 10:20:30. Maybe you know already that the middle number is 32 not 20. Maybe you know as a matter of fact that it is a five digit combination… So please do not send me any letters trying to tell me how the thing is going to work. I read them — I always read them to make sure that I have not already thought of what is suggested — but it takes too long to answer them, because they are usually in the class ‘try 10:20:30’.

(“Seeking New Laws”, page 161 in The Character of Physical Law.)

As a sometime designer (and longtime critic) of widely used computer systems, I have seen similar difficulties appear when anyone undertakes to publicly design a piece of software that may be used by many thousands of customers. (I have been on both sides of the fence, of course.) The design possibilities are endless, but the deep design problems are usually hidden beneath a mass of superfluous detail.

The sheer numbers can be daunting. Even if only one customer out of a thousand feels a need to express a passionately held idea, it can take a long time to read all the mail. And it is a fact of life that many of those strong suggestions are only weakly supported by reason or evidence. Opinions are plentiful, but substantive research is time-consuming, and hence rare. A related phenomenon commonly seen with software is bike-shedding, where interlocutors focus on surface details like naming and syntax… or (come to think of it) like lock combinations.

On the other hand, software is easier than quantum physics, and the population of people able to make substantial suggestions about software systems is several orders of magnitude bigger than Feynman’s circle of colleagues. My own work would be poorer without contributions — sometimes unsolicited, sometimes passionately urged on me — from the open source community. If a Nobel prize winner thought it was worthwhile to read his mail on the faint chance of learning a good idea, I am certainly not going to throw mine away.

(In case anyone is still reading this, and is wondering what provoked a meditation on the quality of one’s inbox contents, I’ll simply point out that the volume has been very high, for many months, on the Lambda-Dev mailing list, where the next version of the Java language is being discussed. Bravo to those of my colleagues who are surfing that wave.)

I started this note thinking there was an odd parallel between the life of the physicist and that of a software designer. On second thought, I’ll bet that is the story for anybody who works in public on something requiring special training. (And that would be pretty much anything worth doing.) In any case, Feynman saw it clearly and said it well.

Monday Apr 04, 2011

JSR 292 support in b136

The OpenJDK7 build b136 was recently released for download. This is an important step forward for JSR 292 because the JVM now supports the new package name, java.lang.invoke. Up until recently, the package has been java.dyn, but we changed the name just before the JSR 292 Public Review.

To minimize test failures, we are using a multi-phase process for the API changes:

  1. b130: 7017414 in langtools: Release javac which supports both java.dyn and java.lang.invoke. This allows us to compile either version of JDK code for JSR 292.
  2. b135: 6839872, 7012648 in JVM: Release JVM which supports both java.dyn and java.lang.invoke. This allows us to run either version of JDK code for JSR 292.
  3. b136: 6839872, 7012648 in JDK: Release JDK which supports only java.lang.invoke. This is the JDK code for JSR 292. Here is a preview from mlvm.
  4. b137 (approx): 6817525 in JVM: Turn on JSR 292 functionality by default. This will allow the JVM to support JSR 292 “out of the box.”
  5. b137 (approx): 6981791 in JVM: Release cleaned-up JVM, purging all java.dyn references. Will also include rename support for MethodHandle.invoke.
  6. b137 (approx): 7028405 in langtools: Release cleaned-up javac, purging all java.dyn references.

As the API slowly adjusts under the Public Review, there will be a few additional changes. Here are the ones which are planned or at least under consideration:

  • rename MethodHandle.invokeGeneric to MethodHandle.invoke (the EG has decided on this one)
  • rename or remove the wrapper method MethodHandles.asInstance (possible rename is MethodHandleProxies.asSingleMethodInterface)
  • Possible finality of some classes and methods (to inhibit subclassing and overrides). Might affect SwitchPoint, ConstantCallSite, other call sites, ClassValue.get, ClassValue.remove, etc.
  • Allow ConstantCallSite subclasses to self-bind (i.e., construct with an implicit mh=mh.bindTo(this)).
  • Add non-varargs overloadings to some varargs methods (for efficiency on simple systems). (Could affect insertArguments, dropArguments, filterArguments. Cf. methodType factories.)

There have been very good discussions about JSR 292 on the mlvm-dev and jvm-languages mailing lists, as well as numerous comments from other sources. Since the Public Review, I have updated the working draft in the OpenJDK sources. You can see the current javadoc for JSR 292 via the JDK 7 download page. Here are the components to the JDK7 documentation:

We will continue to update the documentation during and shortly after the Public Review period. Please continue to experiment with the APIs and to share your experiences.

(Note to JDK7 port users: The link to the preview JAR for b136, in the first list above, allows you to run the current JSR 292 under the b135 JVM. This is a spin from the mlvm patch repository of just the JSR 292 classes. If you put it on your boot class path on a b135 JVM, and if you are daring and lucky, you can preview the b136 functionality. This may be useful if you have a b135-level JVM in one of the porting projects, such as the BSD port.)

Tuesday Feb 08, 2011

JSR 292 formal Public Review

If all goes well, there will be a sixty-day formal Public Review of the specification of JSR 292. I expect this to start in about ten days. (Update: The Public Review period is 2/16/2011 through 4/18/2011. The JDK7 implementation appeared in b136.)

For almost two years, I have been keeping an updated preview of the specification here. This is simply a spin of the Javadoc derived from the current patch set in the Da Vinci Machine Project. I have also frozen a copy of this preview, as of the Public Review, here.

This has has been a long time coming. In some ways, it is sad that it has taken so long. (Four years, yikes!) On the other hand, some very exciting improvements have place in recent months, since last year's JVM Language Summit. JSR 292 has not slowed the JDK 7 process, but where JDK 7 has been slowed for other reasons (such as the Oracle acquisition) I have aspired to use the extra time to make JSR 292 even more mature. In that light, I am very glad that the specification has benefited from those extra months of development. The first working implementation of August, 2008 was pretty good (as an API design), but what we have today is far better.

Here are some recent major changes leading up to Public Review:

  • The package for JSR 292 is no longer java.dyn. It is java.lang.invoke.
  • There is a much simpler variable-arity hook. The withTypeHandler method is gone; now we have asVarargsCollector. Varargs method handles are fully integrated with Java's "varargs" feature.
  • There is clear documentation about how compilers are to recognize that the invokeExact and invokeGeneric methods require special processing.
  • The process for decoding a SAM object into a method handle is based on static methods instead of an interface.
  • MethodType is serializable, like Class.
  • There is a documented SecurityManager API for checking reflective method handle lookups.
  • Exceptions produced by method handle lookups are documented and standardized.

And here are a few of the many changes in presentation:

  • There are @throws specifications for all the corner cases of bad arguments.
  • CallSite and its key methods (getTarget, setTarget, dynamicInvoker) are all abstract.
  • The introductory texts for the major classes have been reworked and the examples rechecked.
  • Obsolete, deprecated, and provisional features have been removed. There are some "historic notes" to acknowledge their previous presence.
  • The term "signature" has been replaced by the term "type descriptor" in most places, for compatibility with the JLS. (Exception: The special term "signature polymorphic" is retained.)

A complete (verbose) account of the differences since my last announcement may be found here. As noted in a recent announcement, this specification is not fully implemented yet. Specifically, the package renaming will take a few weeks of maneuvering; this process has already begun with a modification to javac.

Thursday Dec 23, 2010

123, go!

As of today, 12/23, the OpenJDK 7 project just released build b123. This build contains many changes, including an up-to-date version of the JSR 292 API. If you have been experimenting with JSR 292, you’ll want to try this build. See the javadoc for all the gory details.

Here are some of the differences you might notice:

  • The class CallSite is now abstract, causing an InstantiationError if you try to make one directly, or a problem with a super call if you make a subclass. This breaks a bunch of old code, including mine. The Expert Group decided to refactor CallSite into three subclasses: MutableCallSite, ConstantCallSite, and VolatileCallSite. To fix your code, replace CallSite by one of the subclasses, probably MutableCallSite.
  • The invokedynamic instruction should point to a constant pool entry of type 18, not 17 (a tag that is now deprecated) or 12 (the name-and-type required by the Early Draft Review). The first component of this constant pool entry must be an index into the new attribute BootstrapMethods. For the moment, tag 17 is supported, under the JVM option -XX:+AllowTransitionalJSR292.
  • The class java.dyn.Linkage is deprecated and going away. In particular, registerBootstrapMethod is going away, because the class file format now support static, per-instruction registration, via the BootstrapMethods attribute.
  • The class java.dyn.JavaMethodHandle is gone. Use Lookup.findVirtual (cached in a private static final) and MethodHandle.bindTo to convert a random object to a method handle. Use MethodHandles.asInstance to convert a method handle to a random SAM interface.
  • Direct syntax support for generating invokedynamic instructions in Java code will not be part of JDK 7. (Sorry! Use indify instead.) Exotic identifiers are also out for now, as is the annotation-based BSM specification. We will continue to experiment with these things in the mlvm repository, and some may be adopted into the Lambda project. In fact, we hope that Lambda will integrate method handles somehow, at least providing a way to construct a method handle from a literal expression like Object#toString.
  • Some of the documented argument conversions for method handles are not well supported, especially those involving unboxing or boxing, or primitive widening or narrowing. You can run into this easily by passing a primitive value to invokeGeneric. As a workaround, try casting the offending primitive to Object at the call site. This is bug 6939861.
  • Some of the method handle combinators (aka. transformers) will fail if you work with more than about 10 arguments at a time. This is bug 6983728.
  • Your item here: If you notice other changes that disturb your code, please let me know, so I can adjust this list.

The indify tool has been updated to support the new formats. Its default output uses non-transitional formats. An earlier version of indify also appears in the unit test code for OpenJDK.

It is still the case that you must pass the following options to the JVM to use JSR 292: -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic.

Here are a few more changes that are very likely in the near future:

  • The JVM flags -XX:+EnableInvokeDynamic and -XX:+EnableMethodHandles will be turned on by default. (This is tracked by bug 6817525.)
  • The JVM flag -XX:+AllowTransitionalJSR292 will be turned off by default, causing constant pool tag 17 to be rejected.
  • The class java.dyn.Switcher will be renamed java.dyn.SwitchPoint.
  • The constant and identity functions of java.dyn.MethodHandles may change, losing the overloadings which take MethodType arguments.
  • The variable-arity “hook” for MethodHandle, withTypeHandler is controversial among JVM implementors and may be adjusted or deleted. (To see what variable arity means for method handles, see the method arityOverload around line 1423 in
  • Any remaining stray sun.dyn.\* names in the API are going away, of course. MethodHandle will not have a superclass. (Nor will it have user-callable constructors for building subclasses.)
  • A few items are marked “provisional” in the javadoc; these could still change also.

At year’s end I am deeply grateful to the JSR 292 Expert Group, intrepid early adopters (Dan H., Rémi F., Charlie N., Fredrik O., Jim L., Sundar!), mad scientists (Thomas W., Lukas S., Hiroshi Y.!), conference propagandists (Christian T., Brian G., Alex B., Chanwit K.!) and the whole MLVM community for their enthusiastic, deeply technical contributions to the future of the JVM. Thank you all for the excellent journey so far.

Please accept my personal warm best wishes for a merry Christmas and a happy New Year.

Tuesday Dec 14, 2010

Scheme in one class

One of the secondary design goals of JSR 292 is to give dynamic language implementors freedom to delay bytecode generation until an opportune moment. In other words, we want to encourage mixed-mode execution, bouncing gracefully between interpreted and compiled code... In order to explore this proposition, I decided to build a small Scheme interpreter which could execute interesting programs without dynamically spinning bytecodes. I chose Scheme mainly because of its attractive simplicity (though it has grown over the years). I also want to pay homage to an old exploit called Scheme in One Definition, in which George Carrette coded up a Scheme interpreter in a single file of C code. It is clearly time for Scheme in One Class. [Read More]

Monday Nov 15, 2010

a modest tool for writing JSR 292 code

I have hacked together a classfile transformer, named "indify", which is able to pattern-match some byte-compiled Java programs, and transform them into equivalent programs which use JSR 292 bytecode enhancements, notably invokedynamic... The code is in a Mercurial repository on, all in a single file of less than 1500 lines. [Read More]

Saturday Oct 02, 2010

larval objects in the VM

Or, the ascent from squishy to crunchy.

I want to talk about initialization of immutable data structures on the JVM. But first I want to note that, in good news for Latin lovers (and those with Latin homework), Google has made Latin translation available ad stupor mundi.

That has nothing to do with Java, but it reminds me of a Java design pattern that deserves to be unmasked and recognized: The larval stage. The idea is that every Java data structure goes through a construction phase during which it is incomplete, and at some point becomes mature enough to publish generally. Objects enter the adult stage when their constructor completes. Or, an immutable object’s contents can be built up incrementally, using a builder pattern. In order to make this work better in more cases, I want to give the builder object fully privileged access to the object in its larval state. And I want to these full privileges to extend to the initialization of finals, a privilege which is currently given only to constructors. [Read More]

Wednesday Sep 22, 2010

JavaOne in 2010

This week I gave two talks at JavaOne. Here are my slides. On Monday Brian Goetz and I talked (again, as in 2009) about the future of the JVM in One VM, Many Languages. The room was full of attentive listeners.

On Tuesday evening, I talked about an experiment I did last December combining Rhino with invokedynamic. The talk was Great Thundering Rhinos! (an expedition into JavaScript optimization). That time, the hour was late and the room was not at all full. But the listeners were still attentive. (Thanks, guys!)[Read More]

Monday Aug 16, 2010

advice from a master teacher

Tonight my father and I were talking about education, with the end of the summer and fall classes coming on. He is glad to be retired, but he is still a teacher at heart. I asked him, “What is your best advice to teachers?” Here is the answer he gave, as well as I can reconstruct it. The first word is “Listen”.[Read More]

Wednesday Aug 04, 2010

after the deluge: how to tidy an overflow

Joe Darcy has posted a fine note on the problem of managing integer overflow in Java. This was raised again last week at the JVM Language Summit. Joe’s blog has already attracted some good comments. Here is my comment, which has inflated itself into a blog entry of its own.

The problem is to take two machine words, do a common arithmetic operation on them, and obtain the arithmetically correct results. In particular, it means that at least one bit must be collected besides the machine word of non-overflowing result data. For example (as Joe notes), the extra bit required to report overflow could be implied by an exceptional return. In any case, there are a couple of degrees of freedom in this problem: What we will use the extra bit(s) for, and how to deliever it (or them). After examining a couple of half measures, I will enumerate about ten ways to return normally with a pair of machine words. [Read More]

Wednesday Jul 21, 2010

an experiment with generic arithmetic

Most computer languages let you add two numbers together. This is harder than it looks, since numbers come in a variety of formats, starting with fixed-point vs. floating-point. The logic for numeric addition has to classify its operands, perhaps coerce them to a common format, and then switch to the correct algorithm for that format. Invokedynamic allows the JVM to separately customize and optimize such arithmetic operations, according operand types and context. To put this theory into practice, I tried a first experiment combining invokedynamic with Kawa, a mature implementation of Scheme on the JVM... [Read More]

Thursday Jun 24, 2010

JVM Language Summit agenda is posted

… Next month, we are once again gathering a room full of language and VM developers at Oracle’s Sun Santa Clara Campus, for the three-day meeting known as the JVM Language Summit. This year (like before) we have an excellent set of speakers lined up. I have just posted the agenda…[Read More]

Tuesday Apr 13, 2010

when nerds call customer service

I'm proud of my home network and maintain it out to the phone company point-of-presence. When the service provider's DSL line goes out due to an external short, I need to open trouble ticket with their phone line people. How hard could that be?

Wednesday Nov 25, 2009

tailcalls meet invokedynamic

It is Autumn, and tail recursion is in the air. A JSR 292 colleague, Samuele Pedroni, just raised the question of how invokedynamic might interact with a tail call feature in the JVM. Here are a few thoughts on that subject, which I hope will provoke further discussion. The first few are (I think) not very controversial, but I try to get a little crazy toward the end. Where, do you suppose, is the boundary? [Read More]

Tuesday Nov 10, 2009

VMIL paper on invokedynamic

I have written a paper for VMIL '09 on invokedynamic, which my fellow JVM and JIT geeks may find interesting:
Bytecodes meet Combinators: invokedynamic on the JVM
John Rose, VMIL '09 Workshop at OOPSLA, Orlando, October 2009

The focus of the paper is on evaluating the architectural effect of adding invokedynamic to JVM bytecodes. The description of JSR 292 is partial and provisional but I expect the part I have described is mostly stable. There is a lot of overview of (a) current implementation techniques for JVM languages, (b) how these techniques adapt to invokedynamic, and (c) how a JVM might optimize invokedynamic. The treatment is not specific to HotSpot. I hope it is useful to JVM teams and to dynamic language implementors.


John R. Rose

Java maven, HotSpot developer, Mac user, Scheme refugee.

Once Sun and present Oracle engineer.


« November 2015