Just to clarify one point: > Next time around some loop within the program, yes. > But if by "next time around" you meant the next time the program is executed, > then your understanding was wrong. > > The generated native code is stored in memory during the execution of > the process, but when the process exits, it is discarded.
For rotor, we JIT into a fixed sized buffer. If we are going exhaust the buffer while JITing new code, we will discard already JITed code to make room, before JITing addition code. -- Geoff Shilling ------------------------------------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. ----- Original Message ----- From: "Fergus Henderson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 09, 2002 1:41 PM Subject: Re: [DOTNET-ROTOR] Rotor for FreeBSD > On 09-May-2002, Goldfarb, Christopher <[EMAIL PROTECTED]> wrote: > > -----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). > > Next time around some loop within the program, yes. > But if by "next time around" you meant the next time the program is executed, > then your understanding was wrong. > > The generated native code is stored in memory during the execution of > the process, but when the process exits, it is discarded. > > > >> 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." > > No, it doesn't conflict. > > > Aren't native x86 bits considered priviledged instructions? > > No, not from the point of view of the OS or the hardware. > I think you are confusing the different levels. > > As far as the OS and the hardware are concerned, there are two kinds of > x86 instructions: the normal unprivileged instructions, such as "add", > "mul", "mov", etc., which can be used by any process, and special > privileged instructions, such as "inb", "outb", etc., which can only be > executed by the kernel and device drivers. User-level processes which > want to do I/O will normally invoke the kernel via a system call, and > then the kernel will execute the necessary priveleged instructions on > behalf of the user-level process. > > The CLR is another layer on top. To the CLR, "raw instructions" are in > a sense priveleged. But to the OS, they're not. > > -- > Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit > The University of Melbourne | of excellence is a lethal habit" > WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
