There are two ways to look at this. When the executable program is run and when the
specific set of code itself is run. JIT'd code does not persist from program execution
to execution.
When the program is run the IL is JIT'd the first time a specific set of code is
executed, and what the CPU executes is Native instructions. The following invocations
to that method are pointed directly to that set of Native instructions and no JIT'ng
is necessary.
When the program exits, so goes the JIT'd IL. The IL that is living on disk is the
only thing remaining.
NGen'ng is the exception here.
-Bill Conroy
-----Original Message-----
From: Goldfarb, Christopher [mailto:[EMAIL PROTECTED]]
Sent: Thu 09/05/2002 15:42
To: [EMAIL PROTECTED]
Cc:
Subject: Re: [DOTNET-ROTOR] Rotor for FreeBSD
-----Original Message-----
From: Fergus Henderson [mailto:[EMAIL PROTECTED]]
> On 09-May-2002, Goldfarb, Christopher <[EMAIL PROTECTED]>
wrote:
>> I was describing the CLR process model and how it differs from the JVM,
>> specifically in how the runtime JITs to a file for later retrieval
instead
>> of recompiling each time.
>
> What makes you think that?
Let me clarify - I'm not talking about "recompiling" an app from syntax
candy (C# for instance) to IL, but rather when the runtime du jour executes
a given app for the first time. My understanding was that by default, the
runtime JITs into durable format those sections of the IL that are being
executed, on the fly. Next time around, those instructions are already
compiled and available to be served up (assuming the IL date/timestamp
hasn't changed).
> AFAIK none of the current CLR implementations do that automatically.
>
> The Microsoft .NET CLR can do so if you explicitly ask it to, but it
> has to be done manually...
I thought this was an option only to compile the entire application instead
of the default "bits and pieces as we go", so that users suffer a whopping
performance hit the very first time it's run, but afterwords everything is
ready to go.
>> Thinking on this later, I'm wondering if there are any instances where
the
>> runtime generates raw machine code and leaves the umbrella of OS calls.
I
>> can't imagine this would be the case. Can someone clarify for me?
>
> It's certain machine code that gets generated, but the generated code
> contains only user-mode instructions, including calls to the OS API,
> not privileged instructions such as port I/O.
Doesn't this conflict with the response from "dotnetrotor":
"Rotor on FreeBSD uses a platform adaption layer (PAL), which abstracts
the API calls for easy porting. If you look in the source for Rotor
you'll see that the JITter does generate native x86 code. From the
questions I've seen posed about porting to non-intel, this is the
hardest bit and may require a lot of effort."
Aren't native x86 bits considered priviledged instructions?
Thanks again for your clarification.
Chris
