[Mono-list] Re: bug report for new JIT

[Jeroen Frijters]

Another thing to consider is garbage collection. Hopefully the intern
table has weak references to the strings that the user put in there, but
strings put in there by ldstr shouldn't be gargbage collected (except
when the AppDomain unloads).

Imagine what happens if:

> 	mono_ldstr (...);
> 	mono_ldstr (...);
> 	... repeat for each string in the switch ...
*GC happens (because of another thread)*
> 	check isinterned

If the ldstr strings were garbage collected the isinterned check would
fail.

Regards,
Jeroen

>=20
> -----Original Message-----
> From: Paolo Molaro [mailto:lupus@ximian.com]=20
> Sent: Wednesday, April 09, 2003 15:50
> To: mono-list
>=20
> On 04/09/03 dietmar wrote:
> > > solve also other issues, like the need for the icall for the=20
> > > process_guid lluis found recently and it would lower=20
> memory usage).
> > > Or we can do it just for the string intern pool: have it shared=20
> > > across appdomains (it should not be too complex).
> > >=20
> > > And since this is done at compile time it's way faster than your=20
> > > proposed workaround that needs to call ldstr for each of the case=20
> > > stmts every time the code is executed.
> >=20
> > We already do that, but this does not solve the problem=20
> with multiple=20
> > domains and shared code. So it is not faster, or I don't understand=20
> > what you talk about.
>=20
> For shared code your solution results in this code:
> 	mono_ldstr (...);
> 	mono_ldstr (...);
> 	... repeat for each string in the switch ...
> 	check isinterned
>=20
> Note that the mono_ldstr() calls could be easyly in the tens=20
> or more, like in mcs and corlib. With the other solutions the=20
> mono_ldstr calls are done at method compile time, not each=20
> time the method is executed, so it's faster.
>=20
> I just committed a simple solution to cvs that does a lazy=20
> sync of the intern table across appdomains, it's not the best=20
> solution (that would be having the root domain and=20
> domain-independent strings), but it works and the overhead is:
> 	*) a loop over the existing appdomains when isinterned() is
> 	called on a string interned in a domain different from the
> 	current one (this happens only the first time)
> 	*) a loop over the existing appdomains when isinterned() is
> 	called on a string that was not interned. I guess we'll have
> 	many other scalability issues to fix before hitting this one
> 	when we'll have hundreds of appdomains running....
>=20
> For AOT, you'll have to save in the shared library the tokens=20
> of the ldstr-referenced strings together with each method and=20
> when the method is loaded, you just call mono_ldstr() on the=20
> string tokens associated with the method.
>=20
> > > But this would not solve the issue, since one can always write the
> > > (correct) IL code mcs currently produces and the bug resurfaces.
> >=20
> > Well, "correct" is the wrong word - this is just how you define=20
> > correct behaviour. I think using the C# compiler to handle=20
> the issue=20
> > is much
>=20
> It's not me that defined the behaviour of the CLR, though:-)
>=20
> > An performance of that approach is faster, because you only=20
> slow down=20
> > code which uses switch statements on strings (which is=20
> quite seldom),=20
> > whereas the other approach slows down code all code=20
> containing ldstr=20
> > opcodes.
>=20
> Nope, see above for the performance evaluation:
> 	num_switch_cases mono_ldstr() calls (always) vs
> 	num_appdomains hash table lookups when isintern fails=20
> And non-shared code is not affected.
>=20
> lupus
>=20
> --
> -----------------------------------------------------------------
> lupus@debian.org                                     debian/rules
> lupus@ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com=20
> http://lists.ximian.com/mailman/listinfo/mono-list
>=20