Re: Support for non-unique process labels?

Just an assumption. Atoms have become one of the most commonly used
structures of the language.
So if any kind of atoms become collectable, in a broad sense, this *could*
lead to
frequent recreation (especially for short-living processes) which *could*
lead to cache misses and memory fragmentation.

P.S. I am not a naysayer. Just trying to better understand arguments of any
proposed ideas.

пт, 7 мая 2021 г. в 14:54, Loïc Hoguin <[email protected]>:

> I don't know what makes you think that. What I linked to does not
> eliminate global atoms like we have today, it just adds local atoms
> which are GC. Global atoms still go into the atom table and are never
> GC. They are the atoms used for modules, functions and literals in the
> code. Local atoms would only be used when generating atoms. The
> performance cost would certainly not be devastating.
>
> On 07/05/2021 11:03, Stanislav Ledenev wrote:
> > As far as I understand how VM works implementation of the idea of
> > garbage collectable atoms will lead to devastating consequences. And
> > performance will be the first victim.
> >
> > IMHO cheapest implementation of process labels can be achieved on top of
> > process dictionary (oh, slippery) through some special value. Plus
> > modification of observer app.
> >
> > пт, 7 мая 2021 г. в 11:24, Loïc Hoguin <[email protected]
> > <mailto:[email protected]>>:
> >
> >     What you want is to be able to either:
> >
> >     * register processes using any term and not just atoms
> >     * have garbage collectable atoms
> >
> >     That way Observer will always show the proper name.
> >
> >     Then for logs all you need is for <0.2555.0> to be identified at some
> >     point (in other logs with its registered name + pid for example). Or
> >     hook into logger as others have pointed out.
> >
> >     GC atoms has long been on the wishlist of many people:
> >
> >     * https://www.erlang.org/erlang-enhancement-proposals/eep-0020.html
> >     *
> >
> https://github.com/nox/otp/commit/bf3334c1d2c0e404abaec72a985134def158afcf
> >
> >     It would be fantastic if this could get traction.
> >
> >     Cheers,
> >
> >     On 06/05/2021 16:06, Nathan Long wrote:
> >      > Is there a way to add a non-unique label to a process? If not, I
> >     would
> >      > like to propose that it be added.
> >      >
> >      > The label could be shown with or instead of a PID. I think this
> >     would be
> >      > useful in at least two areas.
> >      >
> >      > First, when observing a running system, the PID is not
> >     descriptive. I
> >      > have Observer open right now looking at part of my system, and I
> >     can see
> >      > one globally registered process name displayed, but everything
> >     else is a
> >      > PID. What are those processes? I might be able to figure it out by
> >      > clicking the process and seeing what its initial call was, but
> >     often I
> >      > can tell is "it's a GenServer." The structure of the system would
> be
> >      > much more apparent if I saw labels like "db_connection" or
> >      > "request_queue_worker".
> >      >
> >      > Second, when reading error messages in logs or an exception
> >     tracker, the
> >      > PID is not useful. For example, I'm looking at an error in Sentry
> >     right
> >      > now that says "Sentry.CrashError error ** (exit) 'stopping because
> >      > dependent process <0.2255.0> died: killed'". I have no idea what
> >      > `<0.2555.0>` was, so I don't know what to debug.
> >      >
> >      > Does this exist or would others support it being added to the
> BEAM?
> >      >
> >      > -- Nathan
> >
> >     --
> >     Loïc Hoguin
> >     https://ninenines.eu
> >
>
> --
> Loïc Hoguin
> https://ninenines.eu
>