http://www.linkedin.com/pub/surupa-biswas/3/641/b08

Optimizer as an AppStore Service
    United States Patent Application 334486.01
    Filed December 15, 2011
Inventors: Surupa Biswas

Sounds like the Cloud JIT for Windows Phone 8 to me.

-Josh

but the phase 'compiling in the cloud' was very confusing, people thought Microsoft just run NGEN on the server and call it a big feature of innovation, that will be lame.

I think 'optimizing' is more appropriate here. Actually Kevin Gallo said apps will 'start faster and run faster', while NGEN or pre-jit might help in startup performance but can do little about runtime performance, so I think this 'Cloud JIT' or 'Cloud Code Generation' thing should be more like optimizing AOT compiler for MSIL, in order to improve the overall performance of managed apps.

* Sometimes the native image is larger on disk.
* Sometimes the native image is slower, how do you tell without testing?
* The apps are sandboxed, so it's not like one app is going to use a library in another.

-Josh 

The main reason for this is because JITting allows code-generation on-box, which potentially means that the code you're running on a client computer is different to the code that was audited by Microsoft during the on-boarding process for the appstore.

Consequently, Microsoft are looking to deprecate JITting for apps distributed through the appstore - at least initially for Windows RT, but later rolling out to all of Windows8.

This also has the benefit that the cloud can do really agressive optimisations, rather than having to perform a trade-off between optimising more and needing to start running the function as soon as possible.

It also has the benefit that it allows Microsoft to be consistent when it starts telling other developers that they're not supposed to use VirtualProtect/VirtualAlloc or build their own JITters in Metro apps when they're doing it themselves for .NET.

Finally it has the added benefit that cloud-JITting means that 100% of your battery power in .NET apps on WindowsRT are spent running code, rather than JITting code, which should stretch your battery life a little while longer.

How to test the retail version of your app for Windows Phone

Before you release your app in the Marketplace, we recommend that you build it as a native image, to test its performance on a device as users will experience it.

When you build your app in Visual Studio, the code is not compiled into a native image, but into a machine-independent Common Intermediate Language (CIL) binary file. (CIL was formerly known as Microsoft Intermediate Language, or MSIL.) This CIL file is what you submit to the Marketplace when you're ready to sell your app. At that time, the binary file is converted from CIL to Machine Dependent Intermediate Language, or MDIL. Finally, when the user downloads your app to a device, the MDIL file is linked to produce a native image. You can repeat these steps in your development environment by changing certain build options in Visual Studio.

The functionality of your app is not affected by the native code generation. However the native image typically starts and runs faster.

To build and test your app as a native image

1. In Visual Studio, on the Standard toolbar, select Device as the deployment target. You cannot test native code generation on onthe emulator.

2. In the Solution Configurations drop-down list, select Release to create a Release build. You cannot generate native code for a Debug build.

3. On the Tools menu, select Options to open the Options dialog box. In the navigation pane, select Debugging.

4. In the list of debugging options, make the following changes:

   1. Deselect the Suppress JIT optimization option.

   2. Select the Enable Just My Code option.

   Click OK to close the Options dialog box.

5. Build or rebuild your app, and test its performance and responsiveness.

Usage:

Microsoft (R) CoreCLR Native Image / MDIL Generator - Version 4.0.50622.1
Copyright (c) Microsoft Corporation.  All rights reserved.

Usage: crossgen [args] <assembly name>

    /? or /help          - Display this screen
    /nologo              - Prevents displaying the logo
    @reponse.rsp         - Process command line arguments from specified response file
    /fulltrust           - Assembly will be run in a full trust domain.
    /in <file>           - Specifies input filename (optional)
    /out <file>          - Specifies output filename (optional with native images,
                           required with MDIL)
    /MissingDependenciesOK - Specifies that crossgen should attempt not to fail if a dependency is missing.
    /Trusted_Platform_Assemblies <path[;path]>
                         - List of assemblies treated as trusted platform
    /Platform_Resource_Roots <path[;path]>
                         - List of paths containing localized assembly directories
    /App_Paths <path>    - List of paths containing user-application assemblies and resources
    /App_Ni_Paths <path[;path]>
                         - List of paths containing user-application native images
                         - Must be used with /CreatePDB switch
    /Platform_Winmd_Paths
                         - List of paths containing target platform WinMDs used for emulating
                           RoResolveNamespace
 Compatability Modes
    /PreWP8App           - Set the Windows Phone 8 "Quirks" mode, namely AppDomainCompatSwitch=
                           WindowsPhone_3.7.0.0 or WindowsPhone_3.8.0.0.
 MDIL Generation Parameters
    /mdil           - Generate MDIL rather than native code. Requires presence of /out switch.
    /nomdil         - create MDIL image with no MDIL code or CTL data structures, use to force
                      fall back to JIT
    /EmbedMDIL      - Embed a previously created mdil data in IL image into native image.
    /fxmdil         - Generate framework assembly MDIL images containing minimal MDIL
 Debugging Parameters
    /CreatePDB <Dir to store PDB> [/lines [<search path for managed PDB>] ]
        When specifying /CreatePDB, the native image should be created
        first, and <assembly name> should be the path to the NI.

C

It means my time window is narrowing, lets see how much I can do before the truth surfaces.

Sofar I saw an MDILBinder.exe inside the emulation image, and apparently there will also be an mdilnigenlibrary.dll. Plus, evey managed assembly .dll or .ni.dll has a .mdil PE section, I hope these are related to CrossGen.exe.

 Also, I saw a HDRLens.mdil.xap somewhere in the vhd.

The word MDIL is not a new thing, we have seen it in Bartok before:

/TargetMdil=<bool> (currently False) Target MDIL rather than native code

/TargetMdilEHPerBB=<bool> (currently False) When targeting MDIL, emit separate EH records for each basic block

/TargetMdilBartokRuntime=<bool> (currently False) When targeting MDIL, assume that libraries include the Bartok runtime

/ClrMdil=<bool> (currently False) Target/consume CLR-MDIL rather than Bartok-MDIL (not complete)

/RedhawkMdil=<bool> (currently False) Target Redhawk-MDIL rather than Bartok-MDIL (currently implies ClrMdil as well)

/RedhawkBaseClassLibrary=<bool> (currently False) Generate MDIL for a Redhawk base class library (include well-known types table in the CTL)

/MdilV2=<bool> (currently False) Use version 2 of the MDIL instruction encoding (automatic/required for x64)

So there were CLR-MDIL, Bartok-MDIL and Redhawk-MDIL, and also MDIL v2, and thats many years ago.

http://www.freepatentsonline.com/y2011/0258616.html

MDIL Instruction Set: Explaining Instruction Formats and Conventions in MDIL Code

This section discusses the binary encoding and the semantics of MDIL instructions.

Introduction

What is MDIL? MDIL is a lower level of intermediate language than MSIL. It gives up on the goal of machine independence—in fact the acronym MDIL stands for Machine Dependent Intermediate Language. MDIL doesn't compete with MSIL—rather, going through MDIL is another step in the compilation pipeline going from source code in languages like C#, Visual Basic®, Managed C++ via MSIL to native code (mark of Microsoft Corporation). MDIL doesn't try to abstract properties of the target processor, but it still provides a layer of insulation against versioning of both managed code and the execution engine MDIL code is compiled for.

MDIL is not directly executable. Instead, a binder reads the MDIL code and produces executable machine code from it. MDIL code is thus reminiscent of object files resulting from the compilation of unmanaged code which are run through a linker to produce final executable machine code. However, pseudo instructions in MDIL may go further than fixups in traditional object files—rather than just fixing up parts of instructions (like an address field), MDIL pseudo instructions may generate new native instructions which possibly differ in length from the pseudo instruction. Thus the MDIL binder is more complicated than a linker because the binder has to adjust the jumps in the resulting native code so they still jump to their intended targets. With this added complexity also comes added power—MDIL code can be robust against base types adding new fields or virtual methods, so it can be considered a solution to the "brittle base class problem".

But I found another interesting thing in that patent:

enum PlatformID
	{
	PlatformID_Unknown = 0,
	PlatformID_Triton = 1,
	};

So that was CLR Triton !

C

7 hours ago, Charles wrote

@felix9: Oh Felix... Don't you have code to write, man?

C

Yes, but this is the coffeehouse right ? I'm here when my code is still compiling......

7 hours ago, contextfree` wrote

I love linkers and loaders

How about 'binders' ??

With Microsoft's cloud controlling all of this for us sounds like  "compile and link" will become "bind and build and bendover". 

http://pastebin.com/e88qNpAG

most of them are the same as in clrjit.dll, but maybe crossgen can do more aggresive cross-module inlining ? http://www.freepatentsonline.com/y2011/0225564.html