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? 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, and in particular it won't get automatically redone if any of the libraries that a program depends on get updated to a later version. So if any of those libraries gets updated (e.g. to fix a security hole), then the pre-jitted code will not get used. In fact, if I understand correctly, in that circumstance the program would run slower than if it hadn't been prejitted at all, due to the overhead of checking the versions numbers stored with the pre-jitted code to see if they match the current versions of those libraries. > He wanted to know if it was actual machine code, > and I said it wasn't - it spits out OS-compliant function calls. We're > still sticking with WinAPI calls on Windows when all said and done, and the > same applies for FreeBSD. > > 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. -- 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.
