On Wed, Apr 11, 2012 at 12:57 AM, Jonathan S. Shapiro <[email protected]>wrote:
> Unfortunately we are treading on the edge of things I am unable to discuss > as a result of being on the Midori team. If the conversation heads off in > the right direction without my leading it, I may be able to comment > selectively. > > On Tue, Apr 10, 2012 at 3:12 AM, Bennie Kloosteman <[email protected]>wrote: > >> Re 2. If you have a single large static system runtime like .NET the >> remaining shared code becomes small... This remaining code is often very >> domain specific and hence well placed in services. In many cases for a >> Singularity type system/ runtime this would reduce the overall system >> footprint significantly >> > > This isn't correct, mainly because there is *no* shared code in a typical > JIT execution. It's certainly possible to use AOT compilation, but I'm not > sure whether the M$ JIT for CLR does so. > There is nothing stopping a JIT patching in a call address for shared code you can even do it on flat memory but its a lot more painful , With .net you can AOT compile (ngen.exe) an assembly ( dll) into binary and the framework assemblies are compiled according to the machine when installed ( for all machines) . Now when your code uses the jit it should just ensure the binary dll is loaded ( with the usual shared code / private data) and patch the call address . Also sing used AOT ( compile on install ?) and only had a rudimentary JIT. It may be that the JIT times for this are too high due to security checks on the assembly but im not aware of this, I also doubt when i start 10 hello world C# programs my memory goes up 200 Meg from multiple copied of the shared framework. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
