Are the CLR & JVM Well Suited For The Manycore Era?

Patrick Logan refers to Ted Leung observing that quad-core and octo-core MacPros don't show anything like linear speedup. This accords with my own fanaticism about the manycore future. A question I don't know the answer to: Do the CLR & JVM have characteristics that dramatically help or dramatically hinder their suitability for manycore hardware?

The CLR & JVM are based on abstract hardware. The virtual machines have some things which immediately jump out as, let's say, "tough" for parallelizability -- both have a model whereby separate threads are responsible for coordinating their own access to shared memory (i.e., fields in objects). On the other hand, they have at least one thing which jumps out as potentially a "very good" thing for parallelizability -- their stacks are conceptually separate from main memory, which may make the threading models easier to evolve (in a world without pointers, data in the stack is inherently local to the current thread.) The "inherently parallelizable" aspect of functional languages arises from their exclusive use of the stack for volatile state, but with the way the stack is generally conceived (as, y'know, a stack) requiring pushing and popping and copying variables from one to another, problems arise when copying large datastructures; thus my thought that maybe the abstraction of the stack could be a "win."

blogroll

social