Tzvetan Mikov (tzvetanmi@yahoo.com) on 10/22/06 wrote:
---------------------------
>S. Rao (sonny@burdell.org) on 10/21/06 wrote:
>---------------------------
...
>>Even further, object creation is normally an expensive
>>process anyway, the barrier might be cheap enough that
>>it amounts to noise in the amount of time it takes
>>to fully initialize an object. So who knows, maybe
>>they just always do it. If I can get ahold of a JVM
>>guy, maybe I can find out what they do on PPC.
>
>Again, I disagree. Object creation is supposed to be an extremely cheap operation,
>ideally comparable in cost to literally pushing the object onto the stack.

I've had a little look at some other languages. What seems to happen is one of three things:-
1. Allocations are done with memory barriers
2. Variables that sit between threads have memory barriers around them
3. Threads are done inside the language runtime rather than the OS, thereby not utilizing multiple processors.
4. Don't both with threads

Smalltalks, Schemes, Ruby, Python and Perl seem to take approach #3. I don't think this has much of a future in a world of many cores and threads per chip.

OCaml, many schemes & lisps, and MLs take option #4 which is arguably worse. Though, for the time-being it simplifies VMs to a fairly useful extent.

Steel bank Common Lisp takes approach #2. The only variables that one thread can access/view in another thread are what Lisp calls "special variables" which more-or-less means global variables.

It seems Java does #1 from what others have said so far. But that seems extremely expensive to me, and I'd be surprised if there isn't something we've missed.