Concatenating atoms

[Thomas Lindgren]

--- "Joe Armstrong (AL/EAB)"
<joe.armstrong@REDACTED> wrote:

> > Thomas Lindgren wrote
> > [atom gc!]
>
>   Nja - Ummm - we're garbing the wrong thing - we
> should be garbing
> the code space and not the atom space, atoms should
> be local to modules
> and not global at all. 
...
> There should not be a global
> atom table in the
> first place - it violates the principle of
> isolation.

Violates it in what way?

The serious issue about atoms as implemented today, in
my mind, is that (a) you may run out of them, (b) once
you have created one, you can never get rid of it.
(Except by restarting the VM.)

> [atoms should be put in per-module atom tables]

How would dynamically created atoms be handled?

> [code should be garbage collected]

I think I agree with this, regardless of the treatment
of atoms, but I'd probably want a mechanism to manage
the various loaded module versions too.(*)

In particular, the great advantage of the current code
model ("as you know, Bob" :-) is never getting space
leaks due to obsolete module versions hanging around.
A requirement should be that new schemes not be too
vulnerable to that either.

By the way, that multithreaded Erlang had code GC,
didn't it? Were there any lessons on how well it
worked?

Best,
Thomas

(*) Actually, I want a lot of things when it comes to
modules :-)



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250