On Dec 27, 2007 6:25 AM, Jonathan Chayce Dickinson <[EMAIL PROTECTED]> wrote: > Sander van Rossen wrote: > > Just to play the devils' advocate; > > > > If we do a full program optimalisation phase on each application > > that's installed on the system and include system/corelib we could > > possibly get a speed improvement compared to using them as a seperate > > lib. > > > Very interesting, however, one slight issue with that: if the user > installs a corlib version 1.0.2.1 on top of a 1.0.0.0 everything will > need to be re-optimized.
On windows you have ngen which basically AOT's an application and puts the compiled version of the app/dll in a cache.. When you use ngen it puts the application in a queue and in the background starts to compile them.. (if you run it before it's compiled it uses the JIT i believe) 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) > > All the functionality that's in system/corelib that wouldn't be used, > > wouldn't be included in the binary. > > > > Also, code memory usage will be far less compared to actuall data memory > > anyway. > > (but then again, executables contain a lot of resources in the form of > > images etc. these days) > > > I guess it also saves the JITter from having to recompile a method each > time a new appdomain asks for it. It could also help reduce memory > fragmentation (I am not 100% sure on that opinion though). Let's not > forget the benefit of paging issues. 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) > Resources are not stored in memory, until they are needed. They are read > from disk the first time round (This was an issue in our company and I > did some profiling to test it). So I guess the code stays small. Okay, that's interesting to know ;) > > Another thing to consider is that we might, eventually, want to be > > able to let applications use different versions of the > > system/corelib.. > > > Then you will need two versions in memory, but you wouldn't have an > instance of the JITted code for each application, only for each library. > The JITter works almost exactly the same, only it only ever compiles > code once (unless the system is rebooted or the code is no longer needed). true, so this is not an issue. > 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 I'm not against this btw. like i said, i'm just playing the devils' advocate here ;) ------------------------------------------------------------------------- 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
