@trans You cannot 'purge the symbol table'. If a symbol used by a method name, etc i= s purged then you will encounter strange problems like: * not being able to call the method * the wrong code gets invoked when you call a method * Ruby crashes=20 Symbols are integral to the implementation of MRI. You cannot change how the= y work this easily. ko1's approach is probably the best, but even then it still has a few issue= s. For example, say you create a GC-able Symbol and pass it to send. That symbo= l will need to be interned, but then you need a way to let the Symbol object= know that it now represents an internal ID (or else you break the property o= f Symbols being unique) =20 On 07/02/2013, at 6:28 AM, "trans (Thomas Sawyer)" <transfire / gmail.com> wro= te: >=20 > Issue #7791 has been updated by trans (Thomas Sawyer). >=20 >=20 > @rosenfeld Just had a thought... maybe we could combine these approaches. M= aybe GCing Symbols is too difficult. But what if it were done manually? Woul= d that be more doable? .e.g >=20 > begin > ... > rescue SymbolExhaustion > purge_symbol_table(0.5) # 50% > retry > end >=20 > This would allow you to continue on, but also log the offence. >=20 > Of course, I say this not knowing what the underlying problem with GCing s= ymbols is, so maybe manually doing is no better. As I said, just a thought. > ---------------------------------------- > Feature #7791: Let symbols be garbage collected > https://bugs.ruby-lang.org/issues/7791#change-35943 >=20 > Author: rosenfeld (Rodrigo Rosenfeld Rosas) > Status: Feedback > Priority: Normal > Assignee: matz (Yukihiro Matsumoto) > Category: core > Target version: next minor >=20 >=20 > Lots of Denial-of-Service security vulnerabilities exploited in Ruby progr= ams rely on symbols not being collected by garbage collector. >=20 > Ideally I'd prefer symbols and strings to behave exactly the same being ju= st alternate ways of writing strings but I'll let this to another ticket. >=20 > This one simply asks for symbols to be allowed to be garbage collected whe= n low on memory. Maybe one could set up some up-limit memory constraints ded= icated to storing symbols. That way, the most accessed symbols would remain i= n that memory region and the least used ones would be reclaimed when the mem= ory for symbols is over and a new symbol is created. >=20 > Or you could just allow symbols to be garbage collected any time. Any reas= ons why this would be a bad idea? Any performance benchmark demonstrating ho= w using symbols instead of strings would make a real-world software perform m= uch better? >=20 > Currently I only see symbols slowing down processing because people don't w= ant to worry about it and will often use something like ActiveSupport Hash#w= ith_indifferent_access or some other method to convert a string to symbol or= vice versa... >=20 >=20 > --=20 > http://bugs.ruby-lang.org/ >=20