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

  -----Original Message-----
  From: [email protected]
[mailto:[email protected]]On Behalf Of J J
  Sent: Monday, June 02, 2008 6:12 AM
  To: [email protected]
  Subject: 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.

There seems to be some confusion in the discussions caused by my comment
about the difficulty of making the VM multi-threaded.   Choosing a different
model for Smalltalk concurrency has almost nothing to do with the point I
was making.  Erlang's model may or may not be a good one (personally I think
it is a nice in a small way following the functional philosophy, but I'm not
at all convinced that passing only lightweight values with no other shared
state is good enough for what people do in the real world).

But regardless of the concurrency model of the target language, if you want
multiple things happening at the same time then the VM needs to be
internally multi-threaded with shared state, regardless of how the threads
communicate in the target language.   The Strongtalk VM stores all the
bytecodes, classes, etc on the same shared heap.   Garbage collection,
reflective modification, etc.  all modify that heap, and those modifications
must be syncronized across all running threads, processes, or whatever.

Of course, you could implement the Erlang model by making a completely
separate copy of the entire VM/heap for each thread, but you can do that in
any language without modifying the VM at all.  That's called an 'OS
process'.  Or you could 'compile' a bunch of lighter-weight kind of
Erlang-style threads into a single thread/process, but such threads won't
run concurrently on a multi-core system.  None of these things have much to
do with making the VM multithreaded.

-Dave



----------------------------------------------------------------------------
    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.
  

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---