On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote: > > > On Dec 27, 2007 2:40 AM, Johann MacDonagh <[EMAIL PROTECTED]> wrote: > > > > On 12/27/07, Bruce Markham <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Why is everyone so adamant about JIT compiling code? If you notice, > > > > Microsoft themselves tends to AOT compile assemblies (see SQL Server > > > > 2005 Manager). My original plan when I started this project was to AOT > > > > everything. When a user downloads a library / application, it comes in > > > > an IL assembly. The first thing the operating system does it AOT > > > > compile it. > > > > > > Most of us were not around when you formulated your "original plan", so > you > > > can't blame us for not knowing for *sure*. Sorry dude. > > > > Sorry, I didn't mean the tone you probably inferred from my statement. > > I'm just lost when it comes to what we're doing now. > > I can understand that. I spent a couple months away from the project, about > 6 months ago, and I was lost when I came back... > > > > > > > But honestly, the JITing is what makes the project semi-special. If you > are > > > AOTing stuff all the time, then you are literally perverting C# into > some > > > cleaner-than-thoughart form of C++. Seriously. And as a side note, you > can't > > > AOT generics code. There still has to be a JIT in the background to > handle > > > generics when they are encountered. > > > > And this is where I get lost. JIT code is nothing more than a > > real-time AOT compiler. Sure, there are a few optimizations it can > > make depending on the situation, but in general, it's the same. > > > > Generics can be AOT compiled. It's not currently implemented with > > Mono's AOT, but they're working on that > > (http://www.mono-project.com/AOT ). > > That, is very curious.
I believe it's possible, but probably just a pain to implement. > > > > > > > > > Microsoft (and even Mono) both AOT core assemblies. (But if you apply my > > > generics comment, you'll know that even the AOTed assemblies, in both > cases, > > > still rely on a VES with JIT.) But there is no reason that our OSes GAC > > > won't have AOTed copies of installed assemblies. AOTing is considered an > > > *extra*, *optional* step. We lose all the joy in what we are doing if we > AOT > > > everything. > > > > To me the special part is the fact that the code was originally > > written in C#. It's easy to maintain, keep secure (requiring all user > > code to be safe), etc... Just because what the user is actually > > running is the actual machine code that the AOT created, doesn't mean > > that it's not elegant. > > But anyone can dump machine-language code to disk. And machine-language code > can't be verified the way CIL can. CIL is safer that way. With AOTed > assemblies everywhere, there is no safety net. No gauruntee that a real .NET > language was used at some point in the past. And with IL - you can always > guaruntee that you can copy the DLL to a friends computer and it will simply > work or not work. No other hassles. I see what you're saying. Well, my overall plan was to ship a AOTed system for the lowest common denominator for each processor architecture (x86, PPC, etc...). The actual installation procedure would have the plain IL assemblies and would AOT them to the specified system. The operating system will still verify the IL assembly before allowing it to run. For my implementation, we have to assume that the kernel and mscorlib and safe. Additional assemblies (especially user made ones), will be verified, AOTed (with the AOT binary cached away somewhere), and ran. > > > > > > > > > > So, yes, in my model, init is AOT compiled as EIC, and the kernel and > > > > mscorlib and AOT compiled as EDC. > > > Well, I think thats what all of us are planning to do right now. Except > > > thats where we draw the line at AOTing (other than the JIT). And > everything > > > else gets JITed. > > > > Now, when you say JIT, do you mean a full JIT implementation (JIT > > compiling methods as they're used), or do you mean JIT compiling the > > entire assembly just before it's executed? > > Both are possible. With the same JIT. Right now DarxKies is working on the > runtime support (boxing/unboxing, stuff like that) - but telling the AOT > (the form of which that has been AOTed and embedded in the kernel), to take > a method and generate machine-language code, is already rather easy. The > only extra work that has to be done is teaching the AOT to reach out into > the RAM around it (instead of a kernel binary that its generating), to get > metadata to link the currently JITing code to. So, I guess my question is, is there any tangible benefit to JIT compiling vs AOT compiling? > > > > > > > > > > > > If you ignore features such as reflection, exception handling, and a > > > > few others, the only thing a running .net assembly needs is a stack > > > > and a heap. The stack stores both the values of structs (which > > > > includes the primitive types), and pointers to instances of classes. > > > > The actual instance of the class is stored on the heap. So, if I have > > > > this C# code: > > > > > > > > int i = 5; > > > > object o = new Object(); > > > > > > > > The stack will contain both the Int32 value 5, and a pointer to the > > > > object class. The heap contains the actual object class, which is > > > > empty. For each object on the heap, we need to store the number of > > > > pointers to it, so the garbage collector can do it's job. Haven't > > > > figured out the best way to do that yet. > > > Actually, .NET and Mono don't do reference counting in that since. They > > > actually, on each collect, scan all fields for object reference and > > > cross-reference with what is allocated. Sounds rough, I know. And I'm > not > > > sure what SharpOS is going to do yet. > > > > > > > Anyway, I'm going to attempt to write a simple AOT, just something > > > > that does exactly what I need. Hopefully I can have a prototype of > > > > what I'm trying to do and we can see if it's a viable course. > > > > > > > > > > Well, we already have an AOT. And it still doesn't do everything you > want it > > > to do (and DarxKies has put alot of work into it, you should definitely > > > check it out). And it doesn't do anything any different really, other > than a > > > couple hacks so that we can generate arch-specific statements (because > we > > > need to interface with hardware), and do some namespace remapping (so > that > > > our arch-specific code is abstracted properly). Nothing fancy, hard, or > > > deleterious to any OS AOTing needs. > > > > I plan on using DarxKies's AOT compiler in the future. It's fantastic. > > However, I just need something quick that will generate the binary I > > need (it's mostly just with the header that I need). > > DarxKies' AOT has been recently made very very quick. On my laptop, it > compiles the trunk kernel (plus a few local modifications) in 5.4 seconds. > Thats 20278 IL instructions, throughout 567 methods in 91 classes. On a 1.4 > ghz machine. I didn't mean quick in that sense. I meant something i can quickly throw together to generate exactly what I want. Once we know that it works, and we decide to do so, we can tweak Darx's AOT (essentially, AOT'ed binaries need a header so the operating system can plug in links to external libraries, and a few other things). > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------- 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
