<div dir="ltr">A<div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">h, I was looking at stale source code where Serial was 3 bits rather than 13.<br><br>Still 28 bits is a pretty small number when it comes to other languages interfacing with Erlang over distributed transport where a new Pid can be used for each RPC call. Finding an available Pid number that could be reused after the counter wrap-around wouldn't be as cheap as merely incrementing a counter. <br>
<br>When the pid counter wraps around, how does the VM ensure that the incremented Pid value doesn't collide with an existing Pid?<br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">
<br></div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">It doesn't seem like upgrading erl_interface to 64 bit representation of pids would be a huge matter, since pid structure already has two 32-bit integers (id + serial), so it would just be necessary to adjust the masks when encoding/decoding values.<br>
<br>So, if there's a way to resurrect this issue and increase the Pid representation to 60bit in a 64bit environment, this would really be helpful.</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Sep 13, 2013 at 12:27 PM, Rickard Green <span dir="ltr"><<a href="mailto:rickard@erlang.org" target="_blank">rickard@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Up to somewhere around the R9 release pids were composed by a 15 bit index into the process table and a 3 bit serial. After that we use 28 bits, i.e., all bits available in an immediate term on a 32-bit machine. Number of bits used as index is determined at boot-time instead of at compile-time.<br>
<br>
This can, quite easily, be extended to 60 bits on 64-bit machines when it comes to the VM. I've already implemented this once in the VM, but dropped it since it required backward incompatible changes and a lot of work in erl_interface/ei. This made us settle for 28 bits on all machines (unfortunately).<br>
<br>
The _PID_NUM_SIZE of 15 bits is more or less only still there in order to make the textual representation of pids look (somewhat) the same as they used to before R9.<br>
<br>
Since 2^28 is a quite small number, pids may be reused quite fast in a system that spawns a lot of processes. All of the 28 bits of the pid is passed over the distribution.<br>
<br>
Regards,<br>
Rickard Green<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, what I meant was:<br>
Why wouldn't the Erlang VM be changed to use 4 bytes (32 bits) for the Serial and 4 bytes (32 bits) for the Id (giving us 46 more bits), so that the sizes match what the External Term Format allows? Is this change on the Erlang VM roadmap?<br>
<br>
On 09/12/2013 04:05 PM, Serge Aleynikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seems to me that you were mistaken as the 4 (id) and 4 (serial) in the External Term Format specification (*) indicate the sizes in bytes rather than in bits.<br>
<br>
(*) <a href="http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011" target="_blank">http://www.erlang.org/doc/<u></u>apps/erts/erl_ext_dist.html#<u></u>id87011</a><br>
<br>
<br>
On Thu, Sep 12, 2013 at 6:22 PM, Michael Truog < <mailto:>> wrote:<br>
<br>
On 09/11/2013 09:58 AM, Serge Aleynikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Presently the PID representation in external term format is limited to the following:<br>
<br>
<a href="http://www.erlang.org/doc/apps/erts/erl_ext_dist.html#id87011" target="_blank">http://www.erlang.org/doc/<u></u>apps/erts/erl_ext_dist.html#<u></u>id87011</a><br>
<br>
./erts/emulator/beam/erl_node_<u></u>container_utils.h:#define ERTS_MAX_PID_NUMBER ((1 << _PID_NUM_SIZE) - 1)<br>
./erts/emulator/beam/erl_term.<u></u>h:#define _PID_NUM_SIZE 15<br>
<br>
ID is limited to 15 bits<br>
Serial is limited to 3 bits<br>
<br>
So in total a PID consists of 18 bits, and therefore it seems that the number of pids on any remote node cannot exceed 2^18 (262144). While it may seem like a large number, when creating a node in other languages that implement Erlang distributed transport (e.g. C/C#/Java) and create/destroy mailboxes, the local pid counter used to create unique Pids can easily go over that limit. The work-around is to cache freed local pids and resurrect them when pid counter wraps around 2^18 boundary.<br>
<br>
This brings the question of whether that limitation is still necessary in the current version of distribution. Internally Pids use a wider representation (is it 28 bits?), so aside for supporting older versions of beam (which can be worked around through flags in distributed transport) is there any valid reason not to increase the pid maximum numbering limit?<br>
<br>
BTW, as a side note, how is the same problem addressed in the beam when the pid ID counter reaches that limit? Does it make it possible that a newly assigned Pid becomes non-unique? (I.e. if some entity still maintains a reference to an old Pid that died, and later after the pid ID counter wrapped around, a new Pid was assigned the same Pid ID number of a previously dead Pid, then the entity that had the reference to the old Pid with the same ID, could send a message to it that would not be valid for the new Pid.)<br>
<br>
Serge<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<mailto:><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote>
Why wouldn't the Erlang VM be changed to use 4 bits for the Serial and 4 bits for the Id, so that the sizes match what the External Term Format allows? Is this change on the Erlang VM roadmap?<br>
<br>
<br>
<br><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Rickard Green, Erlang/OTP, Ericsson AB.<br>
</font></span></blockquote></div><br></div>