[erlang-questions] Fwd: Erlang "memory economics" & pointers pointing to other pointers

[Peter Johansson]

Hi there fellow Erlang-developers/users !

I have been using Erlang in a project of mine for a couple of months (4 -
5) now ( coming from a 10 years Java & Python developer-background )
.....after having evaluating/investigating the language and its
runtime-system first during some 1 - 2 months before the decision was taken
that it address/suits my set of concluded needs very well indeed ( thumbs
up for that  :-)   ).

I'm directing these following few issues/questions towards,
firstly/primarily, persons on the list which are members of or closely
involved/related with the teams behind erlang.org and/or Erlang/OTP at
Ericsson.


The Erlang VM/architecture, as understood by me, aims/strives for keeping
the amounts/occurrences of memory-copy operations to as low as possible.
Natural exceptions to that being message-passing between processes .....and
I/O - receive/write operations.

My first and primary wondering ( or search for clarification on assumptions
....if you like ) is: ..... do this principle yields from the very first
point of local existence ( loaded modules, function-declarations ) ??

If I have say .... a list and a IOlist with elements of deterministic data:

List = "blablabla".
IOList = [<<"bla">>, <<"bla">>, <<"bla">>].

Will List and IOlist be setup, within the heap-stack of an individual
process, as pointers to the original memory-spaces of the lists from the
module-load ??

.....If these lists are used as included parts in later constructs
.......will there then be new pointers setup in the process's heap-stack
pointing to the previous ones ??

Does this mechanism ( if it exist as of above ) re-emerge down/up through
all the functional/operational levels of the process ( with socket-IO as
the entry/exit-point ) ??

Does this mechanism ( if it exist as of above ) yields for all Erlang's
data/term-types .....or is any of those excluded from it ??


If the mechanism exists as assumed so far ....the " in-mutative
data-carrier " - property of Erlang becomes obvious/logical understandable
for both performance & data-consistency reasons as I perceive the situation
in a wider/extended context. An implication become that all concurrent
processes within the node shares all originally deterministic data written
to memory during module loads !?

As an example ....everything assumed/concluded from this point on would
essentially form the whole underlying foundation/reason for why the
third-part library / module collection "ErlyDTL" is considered an
attractive & high-performing tool for Output/Web- templating. It compiles
templates to Erlang modules which then render their outputs from, as I have
understood it, special IOlist-constructs holding alternating
patterns/sequences of binaries ( fixed text part of original template ) &
Funs ( injection/condition/iterator -  statements of original template ).
Only the outputs from these Funs then needs to be allocated/written into
the heap-stack of the present process. Any further/later inclusive use of
the result from the render-operation will, once again, cause new pointers -
to - pointers to be setup in the process heap-stack.


Under the condition that I have assumed/interpreted/understand this
situation correctly ....I think ...indeed ...it should be formalized into a
descriptive/introductory piece of information and put in a "front-line" /
"early chapter"  place/position within the official Erlang/OTP
documentation .... as it truly illustrates something that makes Erlang
stand out extensively in relation to most other high-level languages.


My practical impressions & experience of this language so far have been
exclusively rewarding, encouraging & idea-producing for all the "next to
come" motivations/objectives in my present time project.

Sending my best regards for now / Peter   flexchap at gmail dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141031/420ebff8/attachment.htm>