Erlang Doesn’t Fit The JVM

http://weblog.hypotheticalabs.com/?p=452

by newsit • 17 years ago

44 49 17 years ago

weblog.hypotheticalabs.com

rjprins• 17 years ago

If these are real limitations of the JVM, what does that say about Clojure?

pavelludiq• 17 years ago

I barely know Clojure, but from what i know it has a workaround for the lack of TCO: http://clojure.org/special_forms#toc10

johnm6• 17 years ago

This isn't a complete solution but does handle a lot of cases that non-FP developers will write.

Alas, even though there is TCO in MLVM, it doesn't look like that will get through the JCP in time to get into Java v7. :-(

stcredzero3• 17 years ago

At it’s heart the JVM is designed to run OO languages very efficiently. This is why languages like Ruby and Python are (mostly) easily ported to the platform...

However, the JVM is less suited to running non-OO languages. Languages like Erlang, Haskell, and Scheme provide features, like tail recursion, closures, and continuations, which are not prominent in the mainstream OO world the JVM targets. They depart far enough from the OO model to make the JVM a poor platform choice.

That's strange, because all of the Smalltalk VMs are capable of closures and many of them can do continuations, yet Smalltalk is often cited as one of the purest OO environments. (I'm also fairly sure that tail recursion can be done as a compiler trick.)

That said, there are real limitations of the JVM. Most Smalltalk VMs can be targeted by a Java compiler to do a dandy job as a JVM. It's much harder to target Smalltalk for a JVM, unless you limit the capabilities of the environment. (Particularly runtime compilation.)

ori_b3• 17 years ago

I'm also fairly sure that tail recursion can be done as a compiler trick.

Only for a single function, at least on the JVM. For mutually recursive functions (ie, a() tailcalls b() which tailcalls a()) you either need the VM to do the optimization, or some explicit control over the stack pointer, or implementing your own function call model within one function.

For the first, you would need some sort of new tailcall instruction, or the VM would have to be guaranteed to do tail call optimizations. (You can't really give control of the stack explicitly while keeping things portable and efficient)

For the second, it's workable... if you don't care about interoperating with other languages on the JVM.

10ren4• 17 years ago

I get the impression that Smalltalk is very late-bound, whereas Java is sort of half-late-bound[1]. Late binding enables you to do pretty much anything.

[1] For example: in Java, methods with the same name but different argument types ("overloaded") are statically bound; whereas in Smalltalk, they are dynamically bound. Java dynamically binds methods with the same name and same argument types that are defined in a subclass/implementation ("overridden"). Sounds like a performance tradeoff to me. (Is Smalltalk performance C-like or Python-like?)

nraynaud5• 17 years ago

smalltalk is generaly slow, and it has the same calling system as ruby.

in smalltalk, methods with the same name don't exist. every method on a object has an unique selector. The selector plays exactly the same role as the signature in java there is no difference on this aspect.

jonhohle• 17 years ago

> For example: in Java, methods with the same name but different argument types ("overloaded") are statically bound; whereas in Smalltalk, they are dynamically bound.

In Smalltalk you simply have messages. An object either responds to one or it doesn't, there's no concept of overloading. A method that looks the same, but has a different number of arguments is a different method.

For example, in Java you might have a print method which takes a string, or a method with the same name which takes a format string and a variable number of replacements:

    String print(String s) { ... }
    String print(String s, Object... v) { ... }

Same name, different signatures.

In Smalltalk, those methods would have different names:

    print:f [...]
    print:f args:v [...]

Where the names of the methods are print: and `print:args:` respectively.

Smalltalk generally closer to Python than C in terms of performance.

10ren4• 17 years ago

It's not about methods with different signatures being being different methods, but about when they are bound. If a class has these methods:

  void print(Object obj) {..}
  void print(String str) {..}

and we make the following invocation - which one gets called? The static, compile-time type of the invocation is Object and the dynamic, runtime class of the invocation is String. Which one will select the method?

  Object a = "hello";
  print(a);

In Java, the first method gets called (the one taking an Object argument). Because the compile time type of this invocation is Object, it is bound to the first method, regardless of the runtime class of a. Even if a is a String. It's the compile time type that selects the method, not the runtime class. To select the other method, we need to change the compile time type:

    print((String)a);

noss• 17 years ago

Isn't LLVM a more interesting universal machine to target anyway?

gps408• 17 years ago

Isn't part of the reason for targeting the JVM the ton of libraries you get for free?

ori_b3• 17 years ago

How many of them fit idiomatically into the language you choose to use on the JVM?

nraynaud5• 17 years ago

I'm looking at LLVM at the moment, and I can say that it is far from a JVM/.net .

I wonder if I can invest on it because they will close the gap, or if they are just playing catchup with gcc, in which case there is no future for GC languages.

akeefer2• 17 years ago

I don't know too much about LLVM, but the JVM has a ton of advantages: it's pretty much universally available on all platforms, it uses a fairly trivial set of instructions that make learning the instruction set and using it fairly easy, there's a ton of information out there about it covering everything from GC algorithms to VM flags to bytecode instructions and memory models, and both the Sun and IBM versions have been heavily optimized over the years. It might not be the best fit for every language, but it's a pretty impressive platform to build a language on.

glymor6• 17 years ago

Erlang's VM is unmatched scaling above 16+ cores (for example process migration http://unlimitednovelty.com/2009/01/cutting-edge-of-vm-desig... ) this is something that the java vm hasn't even begun to look at.

framiere2• 17 years ago

That is untrue.

Check http://blogs.azulsystems.com/cliff/ for really impressive work on jvm that works on 800+ cores ... oh yes, and you have constant time garbage collection.

glymor6• 17 years ago

Azul's system is proprietary and only runs on special hardware. The openjdk that's in common use has had essentially no work done on green threads.

And from your link "we have a lite microkernel style OS; we can easily handle 100K runnable threads" it's not the VM that's handling it.

johnm6• 17 years ago

Um, no.

Even discounting specialized hardware+VM solutions like Azul, the regular JVM runs fine on shipping hardware that has lots of cores.

The dominating limiter in practice is actually garbage collection. I.e., very large heaps will drive the scale up vs. out decision way before cores is a serious issue.

glymor6• 17 years ago

See Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law

Even a tiny amount of work spent sequentially (eg a scheduler or gc) can determine performance as the core count ramps up.

Erlang is essentially ahead of almost everyone on minimalising the sequential portion.

jules• 17 years ago

Is Erlang with 16 cores faster than Java with 4?

adammarkey• 17 years ago

I feel your pain with java serialization.

The fact that you cant serialize exceptions to notify systems connected to a JVM that something blew up is just insane.

All objects should be able to be serialized (in binary) from one system to another as long as JVM versions and class libraries match... end of story.

axod• 17 years ago

They can... you just have to do it yourself that's all.

zitterbewegung• 17 years ago

SISC targets the JVM with tail call optimization with some trickery. http://sisc-scheme.org/

nraynaud5• 17 years ago

first class closures are not a JVM problem, but a language problem. Moreover, closures (lexical closures) exists in java itself: an annonymous inner class captures (well, on demand, for perf reasons) all the lexical terms visible at the point of use.

the tail call is a bytecode security problem. Looks like this problem has been solved and will be merged.

akeefer2• 17 years ago

Anonymous inner classes aren't really closures in the more traditional sense, since they require that the captured variables be final; that makes them more restricted than closures generally are in other programming languages. That might not be a problem for Erlang given its write-once variables, but it is a problem for other languages.

We've been working on generating JVM bytecode for our in-house language, which does support a less-restricted version of closures, and we work around that by wrapping closed variables in one-element arrays, though you have to do for both the initial declaration and on every reference to that variable, even outside the closure, which gets really annoying when the closed variable is something passed onto the stack as a function argument, and probably in other cases I'm not thinking about right now. It's definitely workable, it's just messy and incurs more overhead than is ideal.

davidw• 17 years ago

He doesn't mention the Erlang scheduler and processes. Shouldn't be that hard to hack into the JVM, but as I've commented elsewhere, that's only half the battle...

johnbender2• 17 years ago

Yah process scheduling is trivially easy...

johnm6• 17 years ago

If you want a VM that's totally geared towards "dynamic languages" you should definitely check out Parrot ( http://www.parrot.org/ ).

jerf• 17 years ago

Erlang isn't a dynamic language in the sense that Parrot is optimized for, either. Erlang-on-Parrot wouldn't be able to use any other libraries developed for the Parrot ecosystem as they would depend on mutable languages any better than it already can (it would still have to go through the Erlang ports), eliminating a major reason to go to a given VM, and the Parrot VM optimizes a lot of cases that Erlang doesn't care about while missing out on many it does.

Erlang's data structures are not manifestly typed, but in most other ways it is a static language.

hendler• 17 years ago

Ruby language on the Erlang VM -

http://on-ruby.blogspot.com/2009/03/reia-new-dynamic-languag...

johnbender2• 17 years ago

Why would you even bother doing this in the first place. Erlang's VM is one the things that makes it interesting, Not the syntax.

The only reason I can see is the OTP libraries, but then again, why not just use the Erlang VM as you get so much great stuff for Actor based concurrency out of it.

Erlang Doesn’t Fit The JVM

Related Stories