Sander van Rossen wrote:
> 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)
>
It uses the JIT when an uncompiled method is called.
> 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.
>>> 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)
>
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.
>> 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
>
But you can completely write-only the code memory (newer CPUs have this
ability, but we can do it ourselves)... Just a thought.
>
> I'm not against this btw. like i said, i'm just playing the devils'
> advocate here ;)
>
Ayt :).
--
Jonathan Dickinson
-------------------------------------------------------------------------
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
