@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