[Mono-devel-list] [PATCH] Field Layout Optimization

Ben Maurer 05mauben at hawken.edu
Mon Mar 15 09:56:22 EST 2004

String.Intern Method --
If the value of str is already interned, the system's reference is
returned; otherwise, a new reference to a string with the value of str
is returned

String.IsInterned Method --
A String reference to str if it is in the common language runtime
"intern pool"; otherwise a null reference (Nothing in Visual Basic).

I am not sure what you mean by your first comment. String.IsInterned
("abc") will always return true (because abc is a literal in the code,
so it will be interned when the code runs.

>>> "Jonathan Gilbert" <2a5gjx302 at sneakemail.com> 03/15/04 08:12 AM >>>
I don't know about this particular detail for sure, but just thought I'd
point out that the string being interned does not imply that the
copy will always be used. You might want to check string.IsInterned on

Speaking of which, why doesn't Java's string intern table have a way to
check if a string is interned without actually interning it? Just idle


At 08:38 PM 14/03/2004 -0500, you wrote:
>I am not so sure. For example, if you do something like:
>[MyAttribute ("abc")]
>And query for the attribute many times, the string is not interned. It
>is different any time.
>He might have been saying that all strings in the string heap are
>interned at load.
>-- Ben
>On Sun, 2004-03-14 at 18:48, Jonathan Pryor wrote:
>> On Sun, 2004-03-14 at 18:24, Ben Maurer wrote:
>> <snip/>
>> >       * Is it correct to load strings that are stored in literal
>> >         as interned. The reason I did this was to ensure that we
>> >         create a string on each access (which is incorrect).
However, I
>> >         am not sure if it shoudl be interned.
>> See: http://blogs.msdn.com/cbrumme/archive/2003/04/22/51371.aspx
>> .NET automatically interns all strings literals inside the assembly
>> the assembly is loaded.  The blog notes that: 
>>         This is expensive and -- in retrospect -- may have been a
>>         mistake.  In the future we might consider allowing individual
>>         assemblies to opt-in or opt-out.
>> For compatibility, we'll probably want to do the same, which is what
>> you're doing.  So this is the path of least resistance. :-)
>>  - Jon
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>Mono-devel-list mailing list
>Mono-devel-list at lists.ximian.com
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com

More information about the Mono-devel-list mailing list