> > When a dll is updated, it and all the applications that use it are > > simply put back onto the queue... > > There's no reason we couldn't have a similar mechanism.... (eventually) > > > Where you talking about linking all the assemblies statically into one > binary file? That's the impression I got... I suppose we could do > something like that, the the files would get rather big I think.
Well if you do a full program optimalisation phase you can remove all the code that isn't used and optimize the code much better.. The executables wouldn't be *that* much bigger than they are right now... I think there's this document that microsoft released about singularity in which they state that they basically AOT all applications, and apparently it gives a nice boost in speed while keeping most of the benefits of .NET ... > > since memory would be paged in such a way that memory is one continous > > block for each appdomain anyway, and when you unload an appdomain you > > simply release all of it's pages.. i don't think it would be an issue > > really... (right?) > > the data memory is more likely to get fragmented... but then again, > > the garbage collector would fix that by compacting the memory. > > (in fact, the compacting could probably be sped up a lot if the > > garbage collector could move memory pages around) > > > I meant thrashing pages. If all the code is kept in one place you should > have less problems with loading/unloading pages from the disk. Yes, that's true.. although if you start trashing code pages then you probably have some serious memory problems anyway... ;) > >> We could also do some mean code memory protection with this method of > >> doing things. > >> > > > > Well we could (and should!) do that in both situations > > > But you can completely write-only the code memory (newer CPUs have this > ability, but we can do it ourselves)... Just a thought. If you notice, that's one of the ideas i put on the "blue sky" wiki page a long time ago ;) Which of the two approaches would be easiest to implement? Could we possibly try both? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
