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

Paolo Molaro lupus at ximian.com
Mon Nov 29 05:01:56 EST 2004

On 11/27/04 Miguel de Icaza wrote:
> > We need to add the number of cpus in the aot file, so if that changes
> > we won't load it.
> We discussed on IRC a possible approach: there should be a few bits that
> describe the CPU characteristics, and it should be possible to force the
> AOT engine to build with these different bits set.

This is already implemented and has been for a long time. We just need
to expand the stuff that gets added to the file, like the SMP/UP flag.
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.

> So the filenames would encode the properties for which the image has
> been produced for.   mcs.exe.so.5 would mean `SMP and BLAH features
> required'.

Well, SMP is not a feature that is required, since the SMP code is 
correct when run on a UP, while the reverse is not true.
Since the amount of data may be large, we can't encode it all in the file 
name. There is some value in having possibly differently compiled aot
modules, but they should be kept to a minimum. SMP/UP support is
non changing often to be worth the trouble. We could have different
images for fulltrust compiled code and cas-full-security-checks
code, but that's it.
Note that the jit has already the mechanism to force it to compile code
that won't run on the current processor (mostly to debug the egnerated 
code without access to the specific processor), but this should not be
a feature that leaks to the installed aot imegaes: they are specific
to the system they were compiled on.
We need a small management tool that can be used to scan for images that
are no longer usable (because a different cpu was installed, or because
the mono version who created them is no longer available etc), so they
can be easily removed.


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

More information about the Mono-devel-list mailing list