3 ms·

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_

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.html 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 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/ 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-concurrency2.html http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-co...

glymor 18y ago
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.
- johnm 18y ago
  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.
  - glymor 18y ago
    The dispacter is probably a bottleneck, looking at the paper http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf 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.

glymor 18y ago

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.

johnm 18y ago
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.
- glymor 18y ago
  The dispacter is probably a bottleneck, looking at the paper http://lamp.epfl.ch/~phaller/doc/haller07actorsunify.pdf 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.