[erlang-questions] shared data areas (was Re: [erlang-questions] OOP in Erlang)

[Michael Turner]

"Your proposed alternative seems quite complicated compared to the
(optimization) option of letting the FSMs share a common heap, ..."

It does complicate compilation, but at least it requires no changes to
source code, and encourages loosely coupled encapsulation of large state
records.

Garbage collection issues seem to haunt this whole arena.  I wonder if more
compiler smarts would help here as well.

I've read that almost all reference counting overhead (95%?) can be
eliminated by optimizing compilers.  Since using the memory hierarchy
inefficiently is an increasing source of performance problems, even the
remaining overhead of reference counting (i.e., in cases where the compiler
can't resolve the liveness status of data at compile time) might be
worthwhile.  After all, heap use tends to be roughly stack-like.  You'd
probably get much better locality of reference in most cases if you
collected stuff as soon as possible, or at least very soon after it had been
orphaned.

I don't see how SMP *necessarily* breaks reference-counting, though of
course it complicates things.

Processes that build but then "forget" complex data structures only to die
not long after might run more slowly than before, since they'd be doing a
lot of GC that wouldn't be necessary under an
always-copy/infrequently-collect regime.  But I wouldn't be surprised if
everything else sped up, by reaping the advantages of (1) using short-term
memory more efficiently, (2) using less memory overall for longer-term data
by sharing large data structures, and (3) avoiding copy operations
regardless of the size of the data.

-michael turner

On Tue, Aug 17, 2010 at 10:35 PM, Ulf Wiger
<ulf.wiger@REDACTED>wrote:

> Michael Turner wrote:
>
>> "... in my experience, from complex telephony and multimedia apps, it is
>> in fact pretty common to have thousands of small 'clusters' of state
>> machines, each cluster sharing a whopping big state record and taking turns
>> processing different parts of the control flow."
>>
>>
>> But what's behind the decision to structure things that way?
>>
>
> The fact that the signaling carries all information as a single
> session, but when you break it apart, there are lots of different
> state machines in there. You split them into different processes
> in order to avoid interference between state machines. Still,
> the signaling protocol forces them all to pack the data into
> a single state.
>
> Your proposed alternative seems quite complicated compared to
> the (optimization) option of letting the FSMs share a common heap,
> but that is from a *very* cursory perusal. I will try to read it
> more closely later.
>
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
>