I've been in Santa Clara this week for the JVM Summit. It has been a really fantastic experience. The group of attendees was all insanely smart and deeply into language, compiler, and VM design. The nice thing about the JVM Summit was that it was small enough that you got a chance to meet everyone. So it was quite cool to finally meet many of the people who previously I've only known through their blog persona.

I have tons of notes and comments in no particular order...

Fan Presentation

All the talks were video taped, and supposedly will be available - but who knows when that will happen. I gave a short presentation Wed on Fan, specifically on how we tackle portability between the JVM and CLR. You can download the PDF slides here.

JSR/RET Instructions

Apparently everyone but me knew this, but Java has deprecated the jsr and ret instructions which I use the generate try/finally blocks for the JVM. The latest versions of javac gets around this fact by duplicating the finally block in-place of the jsr instruction. This might turn out to a be a serious pain in the butt for Fan, because we need to figure out how to make it work cleanly in fcode where .NET implicitly handles the finally handler. So duplicating the finally handler won't really work unless we add some extra logic. I need to give this one some thought. The Kawa compiler looks like it does it with a clever use of catch Throwable with gotos. For now I'll continue to emit jsr/ret using the old classfile version, but eventually if we need to move to the 1.7 classfile format (which we'll need to use invokedynamic), then this will likely require a breaking change to our fcode format.

URL ClassLoader

Stuart Halloway gave me a tip about creating a custom "fan:" URL scheme and using URLClassLoader instead of my custom FanClassLoader. Sounds like this could have some nice advantages for making Fan code work better with systems which use their own classloader. So I need to investigate this. Stuart also has written a series of Java.next blog articles - he suggested I write up some of the examples in Fan, which I'll probably do when a few minutes to spare.

Lang Interop

We had a break out session on lang interop, which was a little discouraging. Ideally we'd like to make all the JVM languages play together nicely, but that is a really hard problem to achieve. For example what is a String? Is it mutable or immutable, bytes with an encoding or chars, etc? Neal Gafter kind of summed it up nicely in his talk: the only real substrate is Java and its type system - so all need to communicate via Java's definition of String, numerics, etc. The obvious omission is that Java is the only language which doesn't have the notion of first class functions - so it would be nice to fix that since Java is the lingua franca for the JVM languages.

Attila Szegedi presented a project he has been working on called Meta-Object Protocol or MOP. This is an interesting piece of infrastructure to try and make it easier to compose how dynamic langs call other dynamic langs. Originally when Attila posted on the jvm-lang group, I didn't think it really applied to Fan, but now I'm beginning to think that might be one piece of Fan's lang interop puzzle. For example if use the MOP to handle Fan's dynamic invoke operator for "java scripting", then theoretically that would implicitly handle resolving to the right Java method so we don't have to write our own code to deal with method dispatch - the MOP would do the reflection and/or JSR 292 method handles for us (hopefully in a portable fashion). So it might be nice bit of reuse.

Of course Fan also has to the solve the static, compile time issue too - how do we plug in type signatures for Java and/or .NET libraries so the Fan compiler can generate the appropriate non-dynamic calls and do type checking and coercion. So it would be cool to have something like the MOP for static languages too. For example how does a Scala library or Fan library expose its type signatures? Is there a better way to expose them than as just plain vanilla Java classfiles?

Every JVM language has a much better Java interop story than Fan right now, but we have a much more difficult problem to solve since we have to deal with both Java and .NET interop. But I definitely think the language interop is a big issue for the whole community.

Fortress

David Chase gave a talk on Fortress, which if you've never seen it before is a modern Fortran where code includes all the mathematical symbols as valid syntax. The really interesting part for me is how Fortress is trying to solve data parallelism on the JVM. This happens to be a topic near and dear to me, because starting in a few months I will be using Fan for cloud computing. So the idea of how to do "work stealing" and keep all our cores hopping is quite an interesting topic. This was also the reason I got involved with the Wide Finder project. Tim Bray who ran that project was at the JVM Summit too, so that was quite nice to finally meet him.

Clojure

Rich Hickey gave a wonderful presentation on Clojure. Clojure is quite cool (if you like Lisp :-). The interesting thing for me was to hear how he tackled STM. We don't have STM in Fan yet, but I'm planning to tackle that soon - most likely by allowing transactions around Namespace interactions. So Fan's STM will be very coarsely grained.

He has also some wicked cool data structures he has developed for immutability. For example in Fan I have extremely dumb implementations for List.ro and Map.ro - these are shallow copies which do a full copy-on-write if you change the original mutable version. The toImmtuable method always does a full copy (unless already immutable). Rich's classes always return an immutable instance without actually doing a full copy-on-write. I can't profess to actually grok how they really work, but they sound really cool. I think some other languages have incorporated these data structures, and they might turn out to be handy in Fan.

I got a chance to talk to Rich after the last session. He actually started Clojure with both Java and .NET support - just like Fan. He gave up on the .NET side because of the library issue. Of course we are trying to tackle the library issue - and no question, it is a huge problem to tackle. Being at the JVM Summit and seeing what many of these languages can do when explicitly built for the JVM makes me realize what we are trading off for Fan's portability. It always makes you second guess yourself, but I'm still wholly committed to Java and .NET portability as our mission.

Other VMs

Allison Randal gave a talk on the Parrot VM and I got a chance to pick her brain a bit. This is one of the alternate VMs I've considered for Fan (since once you've done two, the third is easy right). It is definitely tailored towards dynamic languages, so it would probably run slower than HotSpot. Plus it is register based rather than stack based, so a little pain there - but wouldn't be too bad since we type all our locals. But I didn't hear anything that made me think porting fcode to Parrot bytecode would be all that hard. One very cool feature of Parrot is that continuations are built-in and cheap. The hard part would be the libraries, sounds like the Parrot VM doesn't really come with any libraries - so we'd have to write C versions of sys, inet, etc or figure out how shim Fan APIs above libraries other languages have done.

One of the designers of Tamarin was also at the summit. He confirmed what I feared, that there is zero support for 64-bit ints. So porting Fan to Tamarin would be really hard. But he gave me a glimmer of hope that might solved in the future. I think we are more interested in porting to JavaScript anyways since it has more reach.

LINQ

Probably one my favorite talks was Mads Torgersen on LINQ, and I was able to catch up with him and get some details about how it is implemented. LINQ is very cool because it conditionally turns lambda expressions into an AST you can access at runtime. The subtle thing I never grokked until today was that lambda vs expr-tree is based on contextual type inference (such as what the caller is expecting). The problem they are solving is using a unified syntax for querying things in memory or externally such as a RDBMS. So having the AST permits generating SQL at runtime. That is something I am quite interested in too, but from a different angle. One of the things that Andy and I know we have to do is create a query API for Namespaces. Namespaces will be the primary vehicle in which we will build cloud databases. So we need to do something very similiar to LINQ - we need to make it easy to express query predicates and projections using natural Fan language constructs (ideally a closure). But we need to capture those expressions into something we can ship around the network or to analyze at runtime to generate query strategies. I'm still not sure whether that is source code, fcode, or some serializable-AST-like-thing.

What is quite interesting is that .NET and Java are taking very different roads in how to handle language extensions. Java is going down the route of method handles and putting a lot of responsibility onto HotSpot to dynamically optimize bytecode into machine code. .NET doesn't really JIT except at load time, so .NET languages (including Fan) can't rely too much on dynamic optimizations. Instead the .NET strategy is to leverage the LINQ work to make more of the AST available at runtime, which can in turn be used to generate IL. This is how the DLR is working. It is an interesting approach. Ironically James Gosling's talk on Thur touched this very subject - was it better to ship around AST models or bytecode models? I don't think we'd really have any non-Java language running on the JVM today if the internals weren't bytecode, since an AST design would be so heavily biased towards Java. But then again in the case of LINQ it is far easier to generate SQL (or maybe something like JavaScript) from an AST instead of bytecode.

We'll definitely be tackling some of those same philosophical problems in Fan in the coming months.

Conclusion

There were tons of other really great talks, not all directly of interest of Fan, but all quite interesting. I think there was fairly general consensus around getting something like value/tuple/fixnum types in the JVM (which is Fan's #1 pain point) and getting support for tail calls. Sounds like the JVM Summit is going to be a annual thing, and that the .NET Lang Symposium is also going to be an annual thing also in the Spring.

getting support for tail calls

Now that's the best news I've heard all week.

Thanks for the update, Brian.

Most interesting post from the JVM Summit I've read yet. I was aware how Javac duplicates finally code but I never quite understood why - anyone?!

Glad to hear JVM and CLR convergence is still a paramount goal for Fan. :)

The toImmtuable method always does a full copy (unless already immutable).

At least it can do a semi-shallow copy if the elements are immutable. I can't think of any way to avoid the full copy if it is an array (i.e. ArrayList), but if it is a linked list (say Link), then you can have:

class Link {
  // this
  List:Link nextElement;
  // rather than
  Link next;
}

Disclaimer: I just made this up. Don't shoot me if it is horribly wrong ;-)

It's well known that money makes people autonomous. But how to act if somebody doesn't have cash? The one way is to get the <a href="http://goodfinance-blog.com">loans</a> and just short term loan.

Brian's presentation was "the business". I have watched it many times over the years :-)