Monday Mar 17, 2014

the isthmus in the VM

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.

Notably, Charles Nutter has followed up on his JVM Language Summit talk (video on this page) by proposing JEP 191, to provide a new foreign function interface for Java…

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

value types and struct tearing

value types and struct tearing

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]

Thursday May 24, 2012

celestial harmony

Listening to music helps me concentrate at work. Music with words is too distracting, but all kinds of classical and jazz works for me, as well as various kinds of atmospheric sounds, natural or constructed.

Lately I’ve been enjoying audio transcriptions of electromagnetic field measurements taken by NASA’s Voyager probe, which I got from iTunes. (My son David, who has a degree in psychoacoustics, turned me on to this.) As has often been noted, the sounds of space are unearthly yet somehow natural, often pleasant and sometimes eerie. There is some sort of deep structure which our earth-trained senses can still respond to. I suppose it has something to do with auto-correlations and self-similar structures at multiple scales in both frequency and time domains. Composers have sometimes chosen to create sounds like this to suggest “spacey” or other-worldly environments. For example, the NASA recordings sometimes remind me, vaguely, of the creepy electronic beeps and bumps heard in Forbidden Planet. The actual sounds from space are less dramatic, as one might expect. But even when they are a little creepy, the NASA sounds provide a very pleasant and unobtrusive background for me as a I hack away on my code.

So why am I not working, but writing a blog entry instead? Well, starting at minute 12 of the track “Sphere of Io”, there are sounds which resemble a women’s choir singing (wordlessly) in rising tone clusters. You can also find this on YouTube, where the tone clusters start at about 7:30.

Recently I have also been listening to Gustav Holst’s The Planets Suite. Planets, of course, is great listening for nerds, both for its own sake and because of the links to astronomy and also (via John Williams) to movie music. I love the first movement, “Mars, the Bringer of War”, for its rowdy energy, and have learned to appreciate the other movements also. But I find the final movement, “Neptune the Mystic”, to be frustratingly anticlimactic. It doesn’t stride triumphantly to an dramatic conclusion, but rather slowly fades out into a women’s choir, which sings (wordlessly) in rising tone clusters.

That’s what suddenly ripped my attention away from work: I heard Io doing a cover of Holst’s final fade-out. You can hear Holst’s choral fade-out at the end of “Neptune”, from about 5:42 onward in the Boston Pops recording. You can also hear it on YouTube, where the fade-out starts at about 6:02.

The most remarkable thing about this, I suppose, is that in reality Holst is not imitating Io (since he wrote it a century ago), and nor is Io’s behavior patterned after Holst. Either the two of them are following a common pattern, or I am indulging in a common human behavior of seeing patterns in noise. I think both of the latter alternatives are true; we humans usually require some basic phenomenal structure to prompt us before we begin to see patterns. In this case, I think the basic structure has to do with slightly dispersed audio-range tones, modulated to wander on the 1-second scale, as I hinted above. (I wonder: If air-breathing extraterrestrials exist, would we enjoy their songs? It seems likely to me at the moment.) The most enjoyable thing for me about this is to contemplate the unity of physical laws as we experience them personally, and as they operate in unearthly places like Io. The proof of this unity made Isaac Newton a rock star and launched modern science, but it has been pondered since humans were human, and is still puzzling today. The ancients called it the music of the spheres, and so do I.

Tuesday May 22, 2012

solar eclipse backyard adventure

Sunday's eclipse was lovely here in San Jose. My sons and I made some impromptu observations in the backyard. The best picture is of crescent-shaped shadows under the leaves on our ash tree.

Monday Apr 02, 2012

Monday at Microsoft Lang.NEXT

We are having a blast at Microsoft Lang.NEXT.

For the record, I posted my talk about Java 8.

[Update 4/06] The videos are already coming out from Channel 9, including my talk on Java 8 (mostly about closures) and an update from Jeroen Frijters on hosting the JVM on .NET.

I recommend Martin Odersky’s keynote ... [Read More]

Tuesday Mar 27, 2012

the OpenJDK group at Oracle is growing

The OpenJDK software development team at Oracle is hiring. To get an idea of what we’re looking for, go to the Oracle recruitment portal and enter the Keywords “Java Platform Group” and the Location Keywords “Santa Clara”.  (We are a global engineering group based in Santa Clara.)  It’s pretty obvious what we are working on; just dive into a public OpenJDK repository or OpenJDK mailing list.

Here is a typical job description from the current crop of requisitions:

The Java Platform group is looking for an experienced, passionate and highly-motivated Software Engineer to join our world class development effort. Our team is responsible for delivering the Java Virtual Machine that is used by millions of developers. We are looking for a development engineer with a strong technical background and thorough understanding of the Java Virtual Machine, Java execution runtime, classloading, garbage collection, JIT compiler, serviceability and a desire to drive innovations.

As a member of the software engineering division, you will take an active role in the definition and evolution of standard practices and procedures. You will be responsible for defining and developing software for tasks associated with the developing, designing and debugging of software applications or operating systems.

Work is non-routine and very complex, involving the application of advanced technical/business skills in area of specialization. Leading contributor individually and as a team member, providing direction and mentoring to others. BS or MS degree or equivalent experience relevant to functional area. 7 years of software engineering or related experience.

Wednesday Mar 21, 2012

value types in the vm

value types in the vm

Or, enduring values for a changing world.

Introduction

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 Integer and 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]

Sunday Jan 29, 2012

sweet numerology keyfob

(...Being a ramble through mnemonics, phonetics, information theory, pi, absolute zero, and cosmology, also touching on rutabagas and conches.)

Sometimes we need to commit a number to short-term memory, such as an street address or parking garage berth. More important numbers (for phones or credit cards, PINs or birthdays) call for long-term memorization although smart phones increasingly fill that gap. But even with a smart phone it is pleasantly useful to have the option to use one’s own brain for such things. To do this, I rely on something I call the Sweet Numerology Keyfob. Before I explain that outlandish phrase, here is some background... [Read More]

Friday Dec 02, 2011

suppressing warnings this month

The OpenJDK community just had a nice sprint cleaning up warnings in JDK code. I did my bit; it was fun.

Two questions came up during reviews, one about the equivalence of wildcards and named type parameters, and one about the best way to handle creation of an array of generic element types.

Here's the quick summary of how to write arrays of generics:

@SuppressWarnings("unchecked")  // array creation must have wildcard
List<String>[] lss = (List<String>[]) new List<?>[1];
In the common case where desired type parameter is wild, there is no need to suppress warnings:
List<?>[] lqs = new List<?>[1];
Class<?>[] cs = new Class<?>[1];

Note that every use of @SuppressWarnings should have a comment. Also, every @SuppressWarnings should be placed on the smallest possible program element, usually a local variable declaration.

Here's an example of removing a deprecation warning. A typical deprecation warning is:

Foo.java:876: warning: [deprecation] String(byte[],int) in String has been deprecated
String x = new String(new byte[0], 0);
           ^
Here a the corresponding fix:
@SuppressWarnings("deprecation")  // String(byte[],int) in String has been deprecated
// and this is actually useful because the fremdish preskittler was exsufflated
String x = new String(new byte[0], 0);
The clarifying comment is a useful way to record any extra information (if known) why the deprecated method is being used.

Wednesday Nov 30, 2011

on coding style

I vastly prefer coding to discussing coding style, just as I would prefer to write poetry instead of talking about how it should be written. Sometimes the topic cannot be put off, either because some individual coder is messing up a shared code base and needs to be corrected, or (worse) because some officious soul has decided, "what we really need around here are some strongly enforced style rules!" Neither is the case at the moment, and yet I will venture a post on the subject. The following are not rules, but suggested etiquette. The idea is to allow a coherent style of coding to flourish safely and sanely, as a humane, inductive, social process.

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

JSR 292 cited by JCP for excellence

This evening in San Francisco I was deeply touched to be recognized at the 9th Annual Awards Nominations of the Java Community Process. On behalf of the JSR 292 Expert Group, I accepted an award for Most Innovative JSR, and another for leading the Expert Group.

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

JSR 292 launched in Java 7

We just finished graduation season for another bunch of students. (Congratulations, Bobby and Joe!) And after about four years of work, it feels to me like JSR 292 has graduated. Oracle launched Java 7 today. I spoke on 292; here are my slides. The webcast will be posted on the Java 7 launch site in a few days.

Thanks, everyone, for your help!

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.

About

John R. Rose

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

Once Sun and present Oracle engineer.

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