<div dir="ltr"><div><span style="font-size:12.8px">> ETS tables are mutable.  Which is why they are not *Erlang* data</span><br style="font-size:12.8px"><span style="font-size:12.8px">structures.</span><br></div><div><span style="font-size:12.8px">Just to clarify, are objects copied when we put/get them from an ets table?</span></div><div><br></div><div>Looks like I mixed and confused some of my statements.<br></div><div>Looks like I want my data structure to reside in the Erlang process' memory, because I don't want to always copy data when I put/get something in/from that data structure.</div><div>However it doesn't necessarily have to be as transparent to the programmer as the Erlang's lists.</div><div><br></div><div>With NIFs I always must copy data between environments. And it looks like enif_make_copy is doing a full copy of an object:</div><div><a href="https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/erl_nif.c#L795">https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/erl_nif.c#L795</a><br></div><div><a href="https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/copy.c#L73">https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/copy.c#L73</a><br></div><div><a href="https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/global.h#L1127">https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/global.h#L1127</a><br></div><div><a href="https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/copy.c#L602">https://github.com/erlang/otp/blob/3b7a6ffddc819bf305353a593904cea9e932e7dc/erts/emulator/beam/copy.c#L602</a><br></div><div><br></div><div>And I can only add a term to the environment, but can not free a term other than freeing the environment entirely with all it's terms.<br></div><div><br></div><div>I would do enif_make_env for each single object that I want to store, but it looks like a bad idea:</div><div><span style="font-family:Arial,Helvetica,sans-serif"><a href="http://erlang.2086793.n4.nabble.com/erl-nif-questions-regarding-resource-handling-td4673810.html#a4673832">http://erlang.2086793.n4.nabble.com/erl-nif-questions-regarding-resource-handling-td4673810.html#a4673832</a></span><br></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> The current implementation of environments from enif_make_env() has a </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">quite large constant </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">memory overhead.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">> A lot of environments with small/few terms in them will </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">not be </span><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">memory efficient.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><font face="Arial, Helvetica, sans-serif">The next step is to make a "custom GC" based on managing these environments like here: </font><a href="https://github.com/fauxsoup/neural">https://github.com/fauxsoup/neural</a></div><div>(hmm, maybe Erlang's GC works like this)</div><div><br></div><div><br></div><div>Well, the more I dive into that, the more I see that adding a data structure to the Erlang VM level is not so easy and doesn't worth it.)</div><div>Thanks for your help.</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 12 July 2016 at 01:44, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=""><br>
<br>
On 11/07/16 9:07 PM, Constantin Kulikov wrote:<br>
>> ETS tables are not data structures in an Erlang process.<br>
<br>
>Anyway, they are mutable(right?)<br></span>
Yes, ETS tables are mutable.  Which is why they are not *Erlang* data<br>
structures.<span class=""><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
and I didn't ask that a new data structure must necessarily reside in an Erlang process.<br>
</blockquote></span>
If we are talking about something that Erlang code has a *name* for<br>
(represented as say a reference) but cannot work with directly, then<br>
adding a data structure to Erlang is pretty much what NIFs are for.<br>
<br>
Objects that are large, long-lived, few, and have explicitly managed<br>
lifetimes are a good fit for that.  Data base connections, special<br>
access to devices, that sort of thing.<br>
<br>
Objects that are small, multitudinous, and evanescent are not.<br>
<br>
The thing is that we are all floundering in the dark because you have<br>
yet to tell us what it is you actually want to add and what problem<br>
you expect to solve by adding it, and for that matter why it needs to<br>
be in the Erlang VM at all instead of being a C node.<br>
<br>
Background: I worked on Xerox Quintus Prolog, which put Quintus Prolog<br>
and Interlisp-D in the same box.  The design we ended up with was the<br>
least painful and most efficient we could devise, and basically Prolog was<br>
given a chunk of the address space and Interlisp-D was given the rest<br>
and cross-language procedure calls involved copying.  We worked hard<br>
to make sure each language's GC had to know as little as possible about<br>
the other.  Around the same time, the Poplog system -- which is open<br>
source these days -- was in flower.  That put Pop-11, Prolog, Common<br>
Lisp, SML, and I think Scheme in the one address space.  It was and is<br>
an impressive piece of work but meant that Prolog and SML performance<br>
suffered.  In contrast, the Prolog component of XQP did not suffer, as<br>
we didn't have to make compromises.<br>
<br>
<br>
</blockquote></div><br></div></div>