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

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

Agreed.

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

Agreed.  This is cleanest way to program.  Being able to see scopes
(actors) and their behaviors clearly, even if I have to work harder to
improve the run-time efficiency of the programming tool is better than
a machine-efficient design that leads to human mental inefficiencies.
People almost always waste more time than machines.

 What's more, it scales
> much better.

This is one of my concerns.  Do we have actual measurements, from
anyone, on latencies for process switching versus thread switching?  I
know that the threads are heavier contexts with possible contention/
locking issues for shared resources, and are generally slower.  They
are slower and more complicated.  I don't see good reasons for their
existence.

> Java threads are big, heavyweight entities, each with their own
> call stack. Erlang can support far many processes than Java can threads.

What is a practical upper bound on the number of processes?  Is there
a maximum count of actors and hence an actor-granularity we need to
respect?

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

Agreed.  What is Strongtalk's concurrency model, if any?  What C++
classes or primitives must be reworked to create an Erlang-like
concurrency model?

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

I don't think anyone wants such a design for Strongtalk.

> 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 we have a specific list of issues and relevant C++ classes we need
to debug/fix 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),

I was impressed by the unboxed-float Mandelbrot-benchmark performance
relative to C.  The two were close enough for me not to feel like I
was missing much by developing exclusively in Strongtalk.  Still, I
don't mind writing C for primitives, where needed.

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

To continue working with Strongtalk, as if it were a serious tool and
not a cool toy, I need:  stability, a graphical debugger, external
interfacing to DDLs, and then a sound concurrency model.

>
> If Strongtalk were robust, we could use it for Newspeak, and bind our
> portable native GUI, updated browsers, debugger etc. to it.

That seems reasonable.  It sounds like an efficient way to get a lot
of the things we need quickly.  What exactly then do we need to fix in
Strongtalk to make it stable/robust?

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

I can put some time into it, starting in about three weeks.  I need to
setup a C++ environment again, on the new machine (octacore).

 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.

We need to understand why the progress has been slow.  Strongtalk
looks like adavanced compiler technology to me.  Why aren't people
working on it?  Is the C++ code difficult to understand?  Is it badly
organized?

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

I am looking now at Newspeak in greater depth...


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