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

[Paolo Molaro]

On 04/09/03 dietmar wrote:
> > solve also other issues, like the need for the icall for the
> > process_guid lluis found recently and it would lower memory usage).
> > Or we can do it just for the string intern pool: have it shared across
> > appdomains (it should not be too complex).
> > 
> > And since this is done at compile time it's way faster than your
> > proposed workaround that needs to call ldstr for each of the case stmts
> > every time the code is executed.
> 
> We already do that, but this does not solve the problem with multiple
> domains and shared code. So it is not faster, or I don't understand what
> you talk about.

For shared code your solution results in this code:
	mono_ldstr (...);
	mono_ldstr (...);
	... repeat for each string in the switch ...
	check isinterned

Note that the mono_ldstr() calls could be easyly in the tens or more, like in
mcs and corlib. With the other solutions the mono_ldstr calls are done
at method compile time, not each time the method is executed, so it's
faster.

I just committed a simple solution to cvs that does a lazy sync of the
intern table across appdomains, it's not the best solution (that would
be having the root domain and 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....

For AOT, you'll have to save in the shared library the tokens of the
ldstr-referenced strings together with each method and when the method
is loaded, you just call mono_ldstr() on the string tokens associated
with the method.

> > But this would not solve the issue, since one can always write the
> > (correct) IL code mcs currently produces and the bug resurfaces.
> 
> Well, "correct" is the wrong word - this is just how you define correct
> behaviour. I think using the C# compiler to handle the issue is much

It's not me that defined the behaviour of the CLR, though:-)

> An performance of that approach is faster, because you only slow down
> code which uses switch statements on strings (which is quite seldom),
> whereas the other approach slows down code all code containing ldstr
> opcodes.

Nope, see above for the performance evaluation:
	num_switch_cases mono_ldstr() calls (always)
vs
	num_appdomains hash table lookups when isintern fails
And non-shared code is not affected.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better