Concatenating atoms

Valentin Micic valentin@REDACTED
Thu Feb 3 22:28:22 CET 2005

>Thomas wrote:
>I think there are several reasons for
> having an atom GC. The basic problem is, every time
> you create an atom, you take one more step towards
> rebooting your node. While the distance to the cliff
> may be long (and may certainly be reached more quickly
> by other means :-) there is currently no way to turn
> back.

Isn't a situatuion that you're describing an anomaly rather than a rule? It
is not so easy to find a system that needs more than 1,000,000 constants.

> If you want to be sure never to create new atoms, you
> need to be careful about:
> - your own code, of course
Sure thing. As I've mentioned, the only reason I ever had a problem was
because of my code.

> - using third party utilities that can create new
> atoms (e.g., file:consult and friends)
or XMERL... granted. I normally put this kind of code on a separate
run-time. So if I want to parse XML encoded L.N Tolstoy's WAR & PEACE it may
crash without affecting the core (i.e. uranium fuel rods).

> - creating new named ets or mnesia tables
I don't know... that is a lot of named ets or mnesia tables. Usually, the
reason why these "objects" are named is to be able to access them. if one
alters the name with every new creation, it somehow defeats the purpose,

> - registering new named processes
I'd say, the same argument applies. Usual system has a reasonably few
regitered processes.

> - contacting new nodes
Hmmm... streching it a bit?

> - loading new modules (module names are atoms)
> - loading new versions of old modules with new
> exported function names (more atoms)

Let's be serious. Why would you want to GC these things in a frist place?

> - other people working on your system after you've
> left

You should not let them ;-).

> I can appreciate that atom GC may be
> difficult to implement well. But not having it still
> seems like an unnecessary complication.

How about release_atom/1 BIF?  Hmmm.... cancel that. What would happen if
one releases an atom of the function that is currently executing? Same goes
for GC. One would need to separate these atoms from that atoms. Is it worth

Wouldn't it be easier to introduce a flag that may decrease/increase the
size of atom table to some custom value, provided that that flag does not
exist already.


More information about the erlang-questions mailing list