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

To: [email protected]
Subject: RE: Status of Strongtalk C++ code: VM stability and progress on a graphical debugger
Date: Mon, 2 Jun 2008 12:16:05 -0700
From: [email protected]










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

I understood that, I was simply pointing out that there is more to Erlang's model then just the "green threads".

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

Well, given that Erlang was used to achieve an unfathomable 9 9's of reliability for phone switches, it would appear to work quite well for what people do in the real world. :)  It doesn't necessarily pass only "lightweight" values either, it can pass very complicated values.  The VM knows that if the data is passing from one OS thread to another, or even between 2 green threads in the same OS thread that no actual copying is needed, and other such sophistication.

 
 
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.

Yes, I point this out all the time, but most people tend to be stuck on the horrendous module that is so dominant today.


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.

Actually all Erlang "processes" are in the same heap and I believe that may even be the case across OS threads in the same VM instance.  Of course they can do this easier since variables can't be modified (i.e. no write contention on a variable).  But not allowing processes to share state also helps here.

None of these things have much to do with making the VM 
multithreaded.
 
-Dave
Well, it depends.  If people are bound and determined to feel like they are running on two CPUs at the same time then VM changes will be required, and it would be better to make the kind of changes that support a high level form of concurrency then chasing Java's (et al) tail.




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





_________________________________________________________________
Give to a good cause with every e-mail. Join the i’m Initiative from Microsoft.
http://im.live.com/Messenger/IM/Join/Default.aspx?souce=EML_WL_ GoodCause
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---