From: Yariv S. <ya...@gm...> - 2006-06-29 00:26:19
|
> > Nahhh - I don't think the problem is that bad. The only applications > that really need to care are apps that > > 1 take input from possibly malicious users and > 2 then do list_to_atom on that input > > pretty rare - a bit like looking out for cross-site > scripting errors. I admit this scenario isn't too likely, but at least speaking for myself, I sometimes try to optimize things too much. One optimization I *almost* attempted during my recent hacking was to represent strings from RPC calls as atoms for extra efficiency, so when ke han explained this I got bit scared by how close I came to making this blunder :) > > > > Can something be done about > > this??? > > Not so easy - there has been a number of proposals on how to GC > atoms. None especially attractive though. Atoms are extremely > efficiently represented today > > 4bitTag + 28bit index/ptr > > So ever 'fooobar_is_better_than_snafu' occupies 32 bits > and thus never use any heap space when created. Hard to beat. > > A gc scheme would either incur heap storage of atoms _or_ > stop_and_sweep the entire node _or_ some clever variations > on that with barriers and thresholds and whatnot. Hard work > for gc inclined masochists. I know - I once wrote the current > 2 generation gc we have in beam today. Thanks for this in-depth explanation! I'm happy I asked :) Best, Yariv |