Attribute to mark a string variable should not be interned - Please ignore

[cheong00]

Tried search but not seeing related discussion here. Apologies if this has been bought up before.

Background

I think there is a rather old problem that, if we run a process (say, Windows Service) that process a lot of long strings that's not repeating, the string intern pool will grow, and in some time point we'll just have to restart the process or unload/reload the application domain to free the memory allocated by string intern pool, because according to C# team many years ago, there seems to be no way to safely unload the string from intern pool without unloading the application domain.

Suggestion

Is it possible to introduce an attribute for class string members or even string variables that, when present, the runtime will not try to intern the string unless explicitly running String.Intern()?

If the runtime do not support this attribute, it can just keep the old behavior, and the additional String.Intern() the developer added will just be no-op.

Possible benefit

This will allow people who need to write long-running application have option to carefully engineer memory usage, and mark memory used by those string variable that we use to store string which will unlikely to store the same string again as safe to be reclaimed again.

Possible alternative implementation

Add some mechanism that when the string stored in such variable no longer have reference, it will be removed from the string intern pool. It will possibly require modifying string intern pool structure, say adding member in string intern records to save this attribute, or to split a "large string heap" for these strings. This region of memory will be safe for GC by revert interning of all strings remaining there, which I suppose the number will be low.

Again the runtime can safely ignore this attribute if not supported.

[YairHalberstadt]

I don't understand. The only strings that will be interned are those that are hard coded literals. There's only a finite number of those, so how can the string table keep growing indefinitely?

[cheong00]

Indeed. I just wrote a small application that reads string data from a file and manipulates it. No matter how I try to twist the string, unless I call String.Intern() at the beginning to the source string, the destination string always isn't interned too.

I'll take it back and come back later when confirmed it's really problem caused by string interning, or the issue reported is improperly addressed as caused by string interning.

[cheong00]

Got more information and please ignore this thread. It's not even related to .NET but Excel and he got the terminology wrong, that got me to write this suggestion.

[bernd5]

Even if it would be an issue - you should open an issue at runtime and not csharplang