[Mono-list] Intel and the CLR?

[Ben Houston]

Hi Antonio,

> Caching binaries on disk sounds like an incredibly bad idea due to
> security issues.  Someone could replace the copy in the cache with a
> program that does something that is completely different and you would
> have no way of telling.

I believe you could sign the cached binaries with a digital signature
generated from the original assembly -- I think that .NET currently does
something like this for versioning as well as security concerns.  But
remember that we only need the cached assembly as secure as the original
assembly for obvious reasons....  Also, it should be possible to have a
personal assembly cache in addition to the global assembly cache -- one
could use the OS's user account security to handle this aspect of it.
Thus the personal cache would be some place the "C:\Documents and
Settings\<username>\..." directory structure on WinNT/2K/XP setups.

> Also, compiling a IL program down to machine
> code makes the program no longer verifiable.

Not totally sure what you mean...  I guess you can either verify it as
JIT-compile time or be able to refer back to the original IL assembly at
run-time in case of errors or such?

> Something that you could
> potentially do is have a single copy of the program in memory if 1 or
> more instances of the program are running.  This sounds hard though
but
> would be very useful if applied at least to libraries.  Another idea
is
> to have some extra information that tells the JIT engine some machine
> specific information about sections of the code (where are the
critical
> loops, what randomness works best for the allocator) so that the JIT
can
> do a better/faster job next time.

Good ideas.  Did you know that Windows XP already stores load-time
pre-fetch information on executables to speed application start-up time?
What you are talking about is extending this type of run-time
application specific profiling/optimization further.  Totally doable.
:-)

Cheers,
-ben houston
http://www.exocortex.org