RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger

Thanks very much for answering this.  At the moment, this group is forwarded to an email I don't read much.

The actor model can, as you say, be added at any time as a library.  One property that Erlang has that would require a VM change is that Erlang itself can and will run in multiple "OS threads".  Each of these threads runs a scheduler and when ever the user creates a new "process" it will go to one of these schedulers automatically.  This lets the programmer gain the speed up of multiple CPUs without the huge amount of pain involved in a fine-grain locked scheme.

I'm also not sure what it would be like adding exactly Erlang's scheme to Smalltalk, but I think it would be a positive.  The biggest difference would be that currently Smalltalk "processes" can share state with other processes, while in Erlang a "process" is more like a Unix process, i.e. no possible way for another process to see the structures inside it.

There are also other options for concurency, e.g. the "futures" model used by the E language and by a system built in Squeak Smalltalk called Croquet.

Date: Wed, 14 May 2008 21:41:16 -0700
From: [email protected]
To: [email protected]
Subject: Re: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger

FWIW I occasionally had to deal with Java's concurrency issues in my previous life at Sun. Briefly:
Java's concurrency model is built around threads that access a shared heap. Shared state and concurrency is extremely difficult to manage; it is very error prone, and people are always battling race conditions and deadlocks.
Erlang uses an actor model.  Each actor (Process in Erlang) has its own thread of control, but they communicate only via asynchronous message passing. No state is shared among actors - only stateless values are passed among them. It's much easier and more natural to program with. What's more, it scales much better. Java threads are big, heavyweight entities, each with their own call stack. Erlang can support far many processes than Java can threads. There are variations of the actor model, and I'm not sure I want the exact version found in Erlang, but actors are a perfect fit with real object orientation, and any version of them is better than the mess found in Java. In the interest of optimization, Java defines a shared memory model where counter intuitive things can happen; maybe half a dozen people in the world actually understand that model; in practice, it doesn't help the performance of concurrent apps at all, as it encourages over locking. I know someone who calls Java a "lock-oriented" language, since every object is a lock.

So I strongly agree that attempting to emulate that style of concurrency support is a complete waste. I think the number one priority for Strongtalk is to make it stable. Do that, and it runs rings around Java for client applications (not very hard, Java has never been a good client platform), regardless of concurrency. To the extent concurrency is a concern, it's because the optimizations done by the VM/JIT aren't really friendly to concurrency - at least not the pre-emptive threading kind Java does. Overall, I don't think concurrency is even very high on the list of things Strongtalk needs. 

If Strongtalk were robust, we could use it for Newspeak, and bind our portable native GUI, updated browsers, debugger etc. to it. In time, we expect to do an actor library as well- regardlesss of what runtime we use. Unfortunately, I cannot justify the kind of serious VM work necessary to get it ready for prime time. When I arranged for Strongtalk's release at Sun I had hoped the open source community would make it robust enough for real use. So far, progress has been rather slow. I hope that will change. If not, maybe at some point I'll get the resources to work on Strongtalk as part of the Newspeak project, but who knows when/if that will happen.

On Wed, May 14, 2008 at 8:39 PM, Shaping <[email protected]> wrote:



To everyone who wants something useful to come of Strongtalk:



> From: [email protected]

> To: [email protected]

> Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a

> graphical debugger

> Date: Wed, 9 Apr 2008 14:06:37 -0700

>

> I myself am not working on it right now, primarily because I'm busy

> with other things, and because the VM is not multi-threaded and it would

> be

> very hard to make it so, which limits my interest in it.



>If you mean "make it so" as in "make it have the multi-thread model Java

>has" then in my opinion it would be a waste of effort to ever do that.  Now

>what Erlang has would be great and I would expect to be much easier to add

>to the VM.



Can we discuss this at length and reach a resolve?



I want to get into the details, evaluate the choices for a

concurrency

model, make a small, concrete, realistic plan, and then execute it.



Or,  I can keep fixing and extending VW, as I have for the last 14

years

(not so bad, but not good either).



Or,  I can cave into Java's readiness for making real, multithreaded

apps

with good-looking GUIs.  Java makes me think of  lots of people, doc,

examples, help, descent standards--and a language with crappy sytax

(and

other problems) to clog your read-think path and keep you from your

expressive best.



>That is lots of information out there as to why the currently popular brand

>of "concurrency" is bad and needs to go away.  Systems that don't have it

>now shouldn't be making huge efforts to add it, but rather just go right

>into more advanced stuff.



Let's get into it and do something.



What is currently wrong with Java's concurrency model?



What is Erlang's concurrency model and why is it better?





Shaping





-- 
Cheers, Gilad






_________________________________________________________________
Make every e-mail and IM count. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Strongtalk-general" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/strongtalk-general?hl=en
-~----------~----~----~----~------~----~------~--~---