Wednesday Apr 30, 2014
Monday Mar 17, 2014
By john.rose on Mar 17, 2014
This is a good time to consider new options for a “native interconnect” between code managed by the JVM and APIs for libraries not managed by the JVM.
This article describes some of the many questions related to native interconnect, along with some approaches for solving them. We will start Project Panama in OpenJDK to air out these questions thoroughly, and do some serious engineering to address them, for the JDK…
the big goal
I think the general, basic, idealistic goal is something like this:
If non-Java programmers find some library useful and easy to access, it should be similarly accessible to Java programmers.
That ideal is easy to state but hard to carry out…[Read More]
Thursday Mar 06, 2014
By john.rose on Mar 06, 2014
This note explains how a notion of “value types” for the VM should protect the integrity of that value type’s invariants, and points out important differences, in memory effects, between “struct-like” and “persistent” designs for values.[Read More]
Monday Apr 02, 2012
By john.rose on Apr 02, 2012
For the record, I posted my talk about Java 8.
Wednesday Mar 21, 2012
By john.rose on Mar 21, 2012
Or, enduring values for a changing world.
A value type is a data type which, generally speaking, is designed for being passed by value in and out of methods, and stored by value in data structures. The only value types which the Java language directly supports are the eight primitive types. Java indirectly and approximately supports value types, if they are implemented in terms of classes. For example, both
String may be viewed as value types, especially if their usage is restricted to avoid operations appropriate to
Object. In this note, we propose a definition of value types in terms of a design pattern for Java classes, accompanied by a set of usage restrictions. We also sketch the relation of such value types to tuple types (which are a JVM-level notion), and point out JVM optimizations that can apply to value types.
This note is a thought experiment to extend the JVM’s performance model in support of value types. The demonstration has two phases. Initially the extension can simply use design patterns, within the current bytecode architecture, and in today’s Java language. But if the performance model is to be realized in practice, it will probably require new JVM bytecode features, changes to the Java language, or both. We will look at a few possibilities for these new features.
[Posted 3/21/2012, updated as marked 3/24/2012 and 3/05/2014.][Read More]
Wednesday Nov 30, 2011
By john.rose on Nov 30, 2011
Maxim M1: Observe, respect, and imitate the largest-scale precedents available. (Preserve styles of whitespace, capitalization, punctuation, abbreviation, name choice, code block size, factorization, type of comments, class organization, file naming, etc., etc., etc.)
Maxim M2: Don't add weight to small-scale variations. (Realize that Maxim M1 has been broken many times, but don't take that as license to create further irregularities.)
Maxim M3: Listen to and rely on your reviewers to help you perceive your own coding quirks. (When you review, help the coder do this.)
Maxim M4: When you touch some code, try to leave it more readable than you found it. (When you review such changes, thank the coder for the cleanup. When you plan changes, plan for cleanups.)
On the Hotspot project, which is almost 1.5 decades old, we have often practiced and benefited from such etiquette. The process is, and should be, inductive, not prescriptive. An ounce of neighborliness is better than a pound of police-work.
Reality check: If you actually look at (or live in) the Hotspot code base, you will find we have accumulated many annoying irregularities in our source base. I suppose this is the normal condition of a lived-in space. Unless you want to spend all your time polishing and tidying, you can't live without some smudge and clutter, can you?
Final digression: Grammars and dictionaries and other prescriptive rule books are sometimes useful, but we humans learn and maintain our language by example not grammar. The same applies to style rules. Actually, I think the process of maintaining a clean and pleasant working code base is an instance of a community maintaining its common linguistic identity. BTW, I've been reading and listening to John McWhorter lately with great pleasure.
(If you end with a digression, is it a tail-digression?)
Tuesday Oct 04, 2011
By john.rose on Oct 04, 2011
These honors arise from a huge amount of teamwork. Together we introduced fundamentally new instructions and data types into the Java Virtual Machine, an undertaking that was both ambitious and complex. Carrying out this work required the dedicated efforts of the JSR 292 Expert Group members, our fellow engineers, corporate sponsors, and the Da Vinci Machine community. It has been and continues to be a pleasure to work alongside such excellent colleagues. Thank you all!
Let's continue to invest in Java standards, building out great computing platforms to run our future on.
Thursday Jul 07, 2011
By john.rose on Jul 07, 2011
Thanks, everyone, for your help!
Monday Apr 04, 2011
By john.rose on Apr 04, 2011
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:
b130: 7017414 in langtools: Release javac which supports both
java.lang.invoke. This allows us to compile either version of JDK code for JSR 292.
b135: 6839872, 7012648 in JVM: Release JVM which supports both
java.lang.invoke. This allows us to run either version of JDK code for JSR 292.
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.
- 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.”
b137 (approx): 6981791 in JVM: Release cleaned-up JVM, purging all
java.dynreferences. Will also include rename support for
b137 (approx): 7028405 in langtools: Release cleaned-up javac, purging all
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:
MethodHandle.invoke(the EG has decided on this one)
rename or remove the wrapper method
MethodHandles.asInstance(possible rename is
Possible finality of some classes and methods (to inhibit subclassing and overrides). Might affect
ConstantCallSite, other call sites,
ConstantCallSitesubclasses to self-bind (i.e., construct with an implicit
Add non-varargs overloadings to some varargs methods (for efficiency on simple systems). (Could affect
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:
http://download.java.net/jdk7/docs/api/java/lang/invoke/package-summary.html — the
http://download.java.net/jdk7/docs/api/java/lang/ClassValue.html — the
ClassValueclass (a distant cousin to
http://download.java.net/jdk7/docs/api/java/lang/BootstrapMethodError.html — the
- http://download.java.net/jdk7/docs/technotes/guides/vm/multiple-language-support.html — a simple introduction to the JSR 292 API
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
By john.rose on Feb 08, 2011
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
- There is a much simpler variable-arity hook. The
withTypeHandlermethod 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
invokeGenericmethods require special processing.
- The process for decoding a SAM object into a method handle is based on static methods instead of an interface.
MethodTypeis serializable, like
- There is a documented
SecurityManagerAPI 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
@throwsspecifications for all the corner cases of bad arguments.
- CallSite and its key methods (
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
By john.rose on Dec 23, 2010
Here are some of the differences you might notice:
- The class
CallSiteis now abstract, causing an
InstantiationErrorif you try to make one directly, or a problem with a
supercall if you make a subclass. This breaks a bunch of old code, including mine. The Expert Group decided to refactor
CallSiteinto three subclasses:
VolatileCallSite. To fix your code, replace
CallSiteby one of the subclasses, probably
invokedynamicinstruction 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
- The class
java.dyn.Linkageis deprecated and going away. In particular,
registerBootstrapMethodis going away, because the class file format now support static, per-instruction registration, via the
- The class
java.dyn.JavaMethodHandleis gone. Use
Lookup.findVirtual(cached in a private static final) and
MethodHandle.bindToto convert a random object to a method handle. Use
MethodHandles.asInstanceto convert a method handle to a random SAM interface.
- Direct syntax support for generating
invokedynamicinstructions 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
- 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
Objectat 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.
It is still the case that you must pass the following options to the JVM to use JSR 292:
Here are a few more changes that are very likely in the near future:
- The JVM flags
-XX:+EnableMethodHandleswill be turned on by default. (This is tracked by bug 6817525.)
- The JVM flag
-XX:+AllowTransitionalJSR292will be turned off by default, causing constant pool tag 17 to be rejected.
- The class
java.dyn.Switcherwill be renamed
java.dyn.MethodHandlesmay change, losing the overloadings which take
- The variable-arity “hook” for
withTypeHandleris controversial among JVM implementors and may be adjusted or deleted. (To see what variable arity means for method handles, see the method
arityOverloadaround line 1423 in SIOC.java.)
- Any remaining stray
sun.dyn.\*names in the API are going away, of course.
MethodHandlewill 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
By john.rose on Dec 14, 2010
Monday Nov 15, 2010
By john.rose on Nov 15, 2010
Saturday Oct 02, 2010
By john.rose on Oct 02, 2010
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
By john.rose on Sep 22, 2010
John R. Rose
Java maven, HotSpot developer, Mac user, Scheme refugee.
Once Sun and present Oracle engineer.