[Mono-devel-list] [PATCH] Move of Interlocked.Increment/Decrement/Exchange I4 to op codes

[Paolo Molaro]

On 11/29/04 Ben Maurer wrote:
> > Of course we should remember to change the aot format every time we change
> > the internal data structures used in the code, or we should add to the file
> > a description of all the dependencies. For example, we embed in
> > the code the offsets of many fields in some runtime structures.
> > To make the representation compact we could take the md5sum of all the 
> > needed data and store that.
> 
> I think there is an easier way to do this. We need to make sure the GUID
> of all the assemblies we depend on has not changed. Why? Field offsets

Sigh, this is already done since like, one or two years.

> could have changed, also, with inlining we might have inlined a method
> that has changed.
> 
> With our current system, every time you do a build, mscorlib.dll is
> built, and thus has a different GUID. This will invalidate every aot'd
> assembly. So no need to look at the runtime really, as the corlib change
> will invalidate it for us.

No, you don't understand the issue.
Run
	grep G_STRUCT_OFFSET mini/*.c
for some examples of the problem. The emitted code has many dependencies
on the runtime internals and those need to be tracked somehow. This has
nothing to do with changes to corlib, which are already handled.
The offsets of course are only part of the issue, there are many other
dependencies on algorithms etc.

lupus

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