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

[dietmar]

On Wed, 2003-04-09 at 13:14, Paolo Molaro wrote:

> > This code makes sure that all case values are interned before IsInterned
> > is called. This code also works with AppDomains.
> > 
> > The AOT compiler also triggers this problem.
> > 
> > Paolo said the the correct fix would be to have some runtime magic to
> > intern all used strings before a method is called. I agree that this
> > would work, but its complex to implement and produces slow code.
> 
> Here is the answer I got from the MS people a year ago when I brought up
> the issue:
> 	Easiest way is just to intern each string that is loaded by ldstr when
> 	you JIT the method containing the ldstr opcode. That way the JITted
> 	version of ldstr can just load the reference that is already held by the
> 	intern table.
> 
> I think it's easier for them, because they use a sort of root appdomain
> where mscorlib is loaded and I guess they intern the strings in this
> root appdomain: maybe someone can write a test that uses ldstr to load
> the same string in two different appdomains and check the string objects have
> the same address. We can either implement this same solution (it would

AFAIK there is no option to make 100% sure that MS produces shared code,
so it is difficult to proove that.

> 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.

> > My suggestion is to modify mcs to produce the same code as csc, which
> > should be easy to implement.
> 
> 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
cleaner solution that implementing those strange hidden runtime
features.

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.

- Dietmar