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...
Erlang Doesn’t Fit The JVM
21–30 of 51 posts
Re: Erlang Doesn’t Fit The JVM
#22Earlier quoted context omitted.
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.
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.
You are correct, I was pointing to cliff click's blog as he his giving back to the community.
Look at http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.h... : an implementation of a non blocking hashmap without lock that scales beautifully on a bunch of cores without the need of their hardware (http://sourceforge.net/projects/high-scale-lib)
As per actor on the JVM open source projects are blooming around such as http://code.google.com/p/actorom/.
Alex Miller did a nice review here of the solutions out there: http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-co...
Re: Erlang Doesn’t Fit The JVM
#23Earlier quoted context omitted.
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.
You are correct, I was pointing to cliff click's blog as he his giving back to the community. Look at http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.h... : an implementation of a non blocking hashmap without lock that scales beautifully on a bunch of cores without the need of their hardware ( http://sourceforge.net/projects/high-scale-lib ) As per actor on the JVM open source projects are blooming around…
I remember his hashmap when he published it, state machines are a great way to do concurrency.
The Erlang way of handling concurrency is to spawn millions of "processes" (threads) obviously these can't be hardware threads so Erlang is hitting problems OS schedulers would handle (or not be able to handle) in the JVM's case.
I would argue that the JVM is eventually going to have to handle the threading itself if it's to support any actor based programming. OS schedulers have other uses they need to be fast for and hardware threads will always have higher overhead. Python's Stackless is perhaps an example of the amount of work it would require.
Re: Erlang Doesn’t Fit The JVM
#24Earlier quoted context omitted.
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 su…
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.
"in smalltalk, methods with the same name don't exist. every method on a object has an unique selector."
Also true of Objective C (as many of you might already know).
Re: Erlang Doesn’t Fit The JVM
#25Earlier quoted context omitted.
You are correct, I was pointing to cliff click's blog as he his giving back to the community. Look at http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.h... : an implementation of a non blocking hashmap without lock that scales beautifully on a bunch of cores without the need of their hardware ( http://sourceforge.net/projects/high-scale-lib ) As per actor on the JVM open source projects are blooming around…
I remember his hashmap when he published it, state machines are a great way to do concurrency. The Erlang way of handling concurrency is to spawn millions of "processes" (threads) obviously these can't be hardware threads so Erlang is hitting problems OS schedulers would handle (or not be able to handle) in the JVM's case. I would argue that the JVM is eventually going to have to handle the threading itself if it's t…
You might want to take a look at e.g., Scala and how it implements actors on the JVM.
It's basically doing a MxN actor to thread-pool scheduling.
Re: Erlang Doesn’t Fit The JVM
#26If these are real limitations of the JVM, what does that say about Clojure?
I barely know Clojure, but from what i know it has a workaround for the lack of TCO: http://clojure.org/special_forms#toc10
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. :-(
Re: Erlang Doesn’t Fit The JVM
#27If you want a VM that's totally geared towards "dynamic languages" you should definitely check out Parrot ( http://www.parrot.org/ ).
Re: Erlang Doesn’t Fit The JVM
#28Erlang'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.
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.
Re: Erlang Doesn’t Fit The JVM
#29Earlier quoted context omitted.
I remember his hashmap when he published it, state machines are a great way to do concurrency. The Erlang way of handling concurrency is to spawn millions of "processes" (threads) obviously these can't be hardware threads so Erlang is hitting problems OS schedulers would handle (or not be able to handle) in the JVM's case. I would argue that the JVM is eventually going to have to handle the threading itself if it's t…
You might want to take a look at e.g., Scala and how it implements actors on the JVM. It's basically doing a MxN actor to thread-pool scheduling.
The dispacter is probably a bottleneck, looking at the paper http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf I can't really tell how it's implemented.
How does the Scala run queue work? eg have a look at the Erlang article I linked to in my first post.
Re: Erlang Doesn’t Fit The JVM
#30Erlang'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.
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.
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.