[erlang-questions] Add a new data structure to erlang VM.

[Jesper Louis Andersen]

On Wed, Jul 13, 2016 at 11:31 AM, Constantin Kulikov <zxnotdead@REDACTED>
wrote:

> Just to clarify, are objects copied when we put/get them from an ets table?


Yes.

Consider they were not. We have an object X in the table.

Process P1 gets X
Process P2 updates X to X' in the ETS table.

Now, according to immutability, P1's X should still be the same, but a
reference to the object is X' in the table now, and thus P1 reads X'
instead, breaking immutability of process P1.

The next case is even funnier:

P1 gets X
P1 sends X to P3
P2 updates X to X'

Note that P3 is one a different node in the cluster. This has to work
seamlessly in Erlang, or you are in deep trouble. In other words, we are
looking at a situation where you have to implement some copy-on-write
scheme underneath in order to make things look like they do today. It may
be possible, but one has to evaluate the implementation complexity over the
efficiency gain. Copying will actually be faster in many cases on modern
CPUs because it implicitly breaks cache conflicts.

In many cases, the trick with ETS is:

* Not storing large objects. Break them apart, so you can request subparts
* Fetch objects once, and subscribe to changes on objects
* Limit copying with ets:lookup_element/3 so you only copy over relevant
parts of a tuple. "copying" an integer is mostly just a register transfer
for instance.

Another thing you may want to care about is latency. If you equip your own
tuple space with a GC, as in NEURAL, you have to account for the latency
when GC occurs. ETS is specifically built for the case where such a GC
latency is unacceptable. This means it is fair to make a trade-off where
lookup latency is worse but predictable, but there will be *no* garbage
collections at all.


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160713/1e823172/attachment.htm>