Also, just for the sake of completeness, be aware that nothing ever says
that a method can only be JITted once--lots of research guys are playing
around with adaptive/learning behaviors inside a managed environment (like
the CLI or Java), such as re-JITting a method based on new criteria (such as
usage statistics). So it's always possible that a JITted method can be
reJITted again at a later point. It's fairly easy to imagine a heuristic
that tracks the number of calls against a method, and reJITs for speed
(taking longer to JIT) after the 10,000th execution, or something similar.
I'm not suggesting that the CLR does this currently; I'm merely marking a
place that says "They *could* do this later, if it turns out to be
beneficial to do so".
Ted Neward
{ .NET && Java } Author, Instructor
http://www.javageeks.com
http://www.clrgeeks.com
----- Original Message -----
From: "Marco Dorantes Martinez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 14, 2002 9:14 AM
Subject: Re: [ADVANCED-DOTNET] Which methods have been Jit complied
> Just for the sake of completeness, JIT compilation occurs the first time
> a method is executed, subsequent calls execute the native code that was
> previously generated in that particular execution.
> The next time the assembly is loaded, the process start all over again,
> or you can choose the other mode of compilation called install-time code
> generation.
>
> See more at:
> http://msdn.microsoft.com/library/en-us/cpguide/html/cpconjitcompilation
> .asp
>
>
> -----Original Message-----
> From: Ian Griffiths [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 14, 2002 9:36 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Which methods have been Jit complied
>
> First of all, be aware that JIT compilation happens every time you run.
> The
> CLR doesn't store the compiled results anywhere permanent - it just JIT
> compiles into memory.
>
> So if by "a set of assemblies" you mean a set of assemblies on disk
> somewhere, the information you seek doesn't actually exist - all JIT
> compiled code is just abandoned when the process exits.
>
> If you mean a set of assemblies loaded in a particular process or
> appdomain,
> then in principal you could find this out - as someone else has already
> pointed out, the profiling APIs let you do this.
>
> This is not wholly trivial. You can't attach a profiler to a process
> that
> is already running, you have to make sure that it gets loaded up front.
> You
> do this by setting a particular environment variable to contain the
> CLSID of
> your profiler - yes, .NET profilers must be implemented as classic
> unmanaged
> COM components.
>
> So if you need to have this information available to you from within the
> CLR, things are a little tricky - conceptually profilers run outside of
> the
> CLR.
>
>
> --
> Ian Griffiths
> DevelopMentor
>
> ----- Original Message -----
> From: "Stefan Finch" <[EMAIL PROTECTED]>
>
>
> Is it possible to take a set of assemblies and see which methods/classes
> have been Jit compiled, and which haven't yet (i.e. not executed)?
>
> You can read messages from the Advanced DOTNET archive, unsubscribe from
> Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
> You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
