Monday May 19, 2008

invokedynamic goes public

After a successful meeting at JavaOne, the JSR 292 EG (expert group) has published its EDR (early draft review) for the invokedynamic instruction. This draft will be updated from time to time (in response to your comments), until August 17, which is the end of the 90-day review period. Check it out!

Update: There are some good conversations going on about the EDR at the jvm-languages Google group. Here are some rough changes to the EDR I will be proposing in response; the EG may choose to make these changes (or something like them) official with an EDR update pushed through the JCP (Java Community Process).

Saturday May 10, 2008

the golden spike

In the Java cosmos we can reckon time in terms of JavaOne conferences. For programming languages on the JVM, the just-finished epoch has seen much progress, and the next epoch looks even better. Here is some of the progress that I am excited about, after bouncing around at JavaOne...

In other news, today (May 10th) is National Train Day. On this day 139 years ago, a ceremonial golden spike was driven at Promontory Summit, Utah, joining the Central Pacific and Union Pacific railways into a single transcontinental line. The continent was very suddenly smaller, because people, goods, and mail could be moved more quickly from coast to coast, a task which was previously done with wagons, horses, and boats. In the years leading up to this watershed event, two railroads were built, with great difficulty and ingenuity, from each coast, to meet at Promontory Summit.

There is a Promontory Summit and a golden spike in our future also... [Read More]

Wednesday May 07, 2008

dynamic invocation in the VM

For several years now, JSR 292 has promised an invokedynamic instruction in one form or another. The problem has been with picking the one form that simultaneously enables a good range of use cases, addresses several architectural challenges in the JVM, and can be optimized by a variety of commercial JVMs. It has been a restless search for “one bytecode to rule them all”.

The EG has decided to propose an answer, providing a hook which refers all important decisions at a dynamic call site out of the JVM and into Java code. This note builds on a previous blog entry, giving more concrete details and use cases. The current design makes heavy use of method handles, which greatly reduces complexity and clarifies the various roles of language implementors and the JVM. [Read More]

Tuesday May 06, 2008

JSR 292 meeting at JavaOne 2008

Hello, JSR 292 observers and language implementors!

The JSR 292 Expert Group met today at JavaOne.

There were representatives from three major JVMs and two dynamic languages (Groovy, Jython).

Here are some of my notes from that meeting. I hope you find them interesting...

[Read More]

Monday May 05, 2008

interface injection in the VM

“Self-modifying code...” used to be a phrase always uttered (by us hackers) with tones of both admiration and dread. Operating systems and VMs are required to support it (always, in the loader). Aspect oriented programming has made a cottage industry of it. I still fear it, and when I hear customers ask for an API to edit classes in the JVM, I always reach for an alternative, a prescription subtitute for the illegal substance. Inteface injection is a good substitute for a surprisingly wide range of use cases; perhaps it can handle your use case for self-modifying code also.

Interface injection (in the JVM) is the ability to modify old classes just enough for them to implement new interfaces which they have not encountered before. Here are the key design points, in brief... [Read More]

Sunday May 04, 2008

continuations in the VM

Or, how to finish a job twice.

Or, anything worth starting is anything worth starting is anything worth starting is anything worth starting is ...

A continuation, simply put, is a reference to the rest of some program P, as of some given point in the midst of P. It is an interesting design problem to introduce continuations into the JVM. I don't know of a full design for JVM continuations, yet, but it's possible to observe both the easy and the hard parts, and to survey some of the reasons we should care. [Read More]

Wednesday Apr 16, 2008

method handles in a nutshell

The JVM prefers to interconnect methods via static reference or dispatch through a class or interface. The Core Reflection API lets programmers work with methods outside these constraints, but only through a simulation layer that imposes extra complexity and execution overhead. This note gives the essential outlines of a design for method handles, a way to name and interconnect methods without regard to method type or placement, and with full type safety and native execution speed. We will do this in three and a half swift movements...[Read More]

Wednesday Apr 09, 2008

serious and funny about side effects

We just had a good conversation in the JVM Languages group about how memory is getting weird these days, and how microbenchmarks have always been weird. Please include in this weblog, by reference, my musings on memory and JVMs.

Kudos to Vladimir Sizikov for a nice collection of follow-up links. I was very glad for the introduction to Ulrich Drepper’s paper. He also refers to a new wiki on Hotspot implementation, inspired by and serving the OpenJDK, in which I and others are collecting information to help language and JVM implementors understand how Hotspot works, how to make it better, and how to byte-compile for performance.

Finally, if like me you’ve heard but never quite believed the story about how functional languages fix all the problems with side effects and you laugh at the funny papers, you’ll like this little fable about the perils of mutability, in programming languages. It provides an arresting, hard-hitting, and ultimately crushing new perspective on Hindley-Milner type checkers.

Wednesday Mar 12, 2008

fixnums in the VM

Or, the headless object rides again.

Language-specific VMs often use pseudo-pointers with an immediate “payload” to represent a commonly used subset of numbers, and also “headerless” representations for small but ever-present types like Lisp’s cons cell. The JVM can support fixnums and other headerless objects for the sake of these languages, and even for Java. The idea is to make ordinary object pointers (sometimes called oops) coexist with more specialized formats for headerless objects, which we will call iops and xops. The techniques are mature and well-known, and the overheads (of extra tag checking before pointer usage) can be controlled by optimizations already used widely in JVMs.

We will examine low-level encoding techniques, and investigated how to integrate these concepts into the JVM. Although a language implementor might prefer to try these techniques in the closed environment of a from-scratch, specialized VM, it is probably more profitable in the end to incorporate them into an optimized, mature JIT and GC, such as the Open JDK project. [Read More]

Friday Feb 01, 2008

Bravo for the dynamic runtime!

This week several of us from Sun attended the Lang.NET Symposium. The symposium was intensely technical and even downright inspiring. Our hosts kindly welcomed presentations from some of us at Sun; we introduced the Da Vinci Machine project. The centerpiece of the conference was the new Dynamic Language Runtime which factors out the reusable logic that glues dynamic languages on top of the CLR.

Why am I suddenly excited about Microsoft technology? Two or three reasons. First, the DLR (with IronPython and IronRuby) is another evidence that we are in some sort of renaissance or resurgence of programming language design. The second thing that excited me at Redmond was a striking case of parallel evolution between the DLR over the CLR on one hand and the Da Vinci Machine over the JVM on the other side... The final reason is that I am excited for the customers of the JVM, because they will also enjoy the new languages in an expansive open-source community, and on their choice of blazingly fast Java virtual machines. [Read More]

Wednesday Jan 23, 2008

symbolic freedom in the VM

Or, watching your language with dangerous characters.

The JVM uses symbolic names to link together the many hundreds of classes that make up an application. Symbols in the JVM are represented in a uniform syntax, a counted sequence of Unicode characters. The JVM can readily accept class, package, method, field, and type names which could be any string, not just the strings accepted by the Java compiler.  Let's call such names “exotic names”.

The JVM originally inherited symbol spelling restrictions from the Java language, but in recent years it has removed most restrictions. This note describes how to remove the remaining restrictions, by presenting a universal mangling convention to encode arbitrary spelling strings. (Updated 9/01/2012.)[Read More]

Tuesday Jan 22, 2008

anonymous classes in the VM

Or, showing up in class without registering.

One pain point in dynamic language implementation is managing code dynamically. While implementor’s focus is on the body of a method, and the linkage of that body to some desired calling sequence, there is a host of surrounding details required by the JVM to properly place that code. These details add noise to the implementor’s task, and often enough they cause various execution overheads. Anonymous classes can partially address these problems... [Read More]

Thursday Dec 13, 2007

Notes on an Architecture for Dynamic Invocation

In a previous post I enumerated the various parts that go into a call site in the JVM. In order to support the program structure of other languages, especially dynamic languages, the JVM must extend the present schemes of method definition, invocation, and linkage.

The key new requirements are dynamic relinking, programmable linkage, programmable guards, descriptor polymorphism, and method handles.

In brief:

  • dynamic relinking allows dynamic linkage decisions to be revoked
  • programmable linkage allows dynamic linkage decisions to be made reflectively by “bootstrap methods”
  • programmable guards allows call sites to select among overloaded methods according to language-specific rules
  • descriptor polymorphism allows call sites and adapters to be managed and connected generically
  • method handles let bootstrap code and call sites refer directly to bytecoded methods

[Read More]

Tuesday Nov 13, 2007

A Day with PyPy

Yesterday, Charles Nutter and I played host to a roving band of PyPy researchers. Their aim is to get people interested in their new techniques in dynamic language compilation, and they succeeded with us. I had a special goal to figure out how the JVM might be useful in their world.

Here are some bits from the conversation that stick in my memory...[Read More]

Monday Oct 29, 2007

Anatomy of a Call Site

In the Java Virtual Machine, method calls are the way work gets done. This note is a slightly simplified description of the parts of a call site and what they do. I will also sketch some of the implications of this design on the JVM’s support for languages other than Java.

Call, in Fourteen Parts

Here are the parts that make up any method call, as found in the JVM bytecodes:

  • bytecode instruction — the actual calling instruction in the bytecode stream
  • symbolic name — a fixed identifier (a string)
  • symbolic descriptor — a fixed tuple of argument and return types (a formatted string)
  • symbolic type — a fixed symbolic reference to a type (class, array, or interface)
  • symbolic method — symbolic reference to the method (if any) of the given symbolic type, name, and descriptor
  • resolved type — a fixed, loaded type which matches the symbolic type
  • resolved method — a fixed, loaded method which matches the symbolic method
  • receiver — optional, a variable object reference
  • receiver type — optional, a variable class or array type, derived from the receiver
  • arguments — a variable tuple of primitive or reference values (types derived from the descriptor)
  • actual method — a variable method, the actual entry point of the call (not symbolic)
  • return value — an optional variable primitive or reference value (type derived from the descriptor)
  • thrown exception — an optional variable exception (or other throwable) produced instead of a return value
  • exception handlers — zero or more continuation points in the same method, marked by exception types

[Read More]
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