ExamGuru IT/.Net Guru : NOT ANSWERED BEFORE: ASPX native code compilation question on ASPFriends.com 'aspngfw' list

.NETGURU

NOT ANSWERED BEFORE: ASPX native code compilation question

Messages

Related Types

This message was discovered on ASPFriends.com 'aspngfw' list.
Responses highlighted in red are from those people who are likely to be able to contribute good, authoratitive information to this discussion. They include Microsoft employees, MVP's and others who IMHO contribute well to these kinds of discussions.

Johnson, Peter

I asked this question Friday afternoon on these two list servers and got no
response. So here's another try:
==========

There has been some confusion over when/how often ASPX pages are compiled
from their MSIL assemblies to native code. I've read other members (on
aspngfreeforall) and books ("Introducing .NET" by Wrox) that seem to say
that native code is cached between page requests, and I've read/heard that
the assembly is JIT compiled to native code for each page request (although
the MSIL assembly is definitely cached). Information I've gotten from
Microsoft thus far via documentation, a webcast, and an e-mail, has been
ambiguous. So is the native code regenerated every time the page is
requested, or is it only JIT compiled once? This is a long e-mail
(necessarily because it's not a simple subject), so bear with me.

Let's say I create two ASP.NET pages called MyPage1.aspx and MyPage2.aspx. I
start the server (the physical machine and IIS), then call each page twice.
Here's what I understand to happen.

MyPage1.aspx first call - ASP.NET ISAPI application is loaded, along with
CLR and supporting libraries/files; MyPage1.aspx is compiled to MSIL
assembly; MSIL assembly is saved in a temporary directory on disk; needed
methods in the MSIL assembly are JIT compiled and their result stored in
memory; JIT native code is run, then unloaded from memory

MyPage1.aspx second call - needed methods in the MSIL assembly in temporary
directory are JIT compiled again and their result stored in memory; JIT
native code is run, then unloaded from memory

MyPage2.aspx first call - MyPage2.aspx is compiled to MSIL assembly; MSIL
assembly is saved in a temporary directory on disk; needed methods in the
MSIL assembly are JIT compiled and their result stored in memory; JIT native
code is run, then unloaded from memory

MyPage2.aspx second call - needed methods in the MSIL assembly in temporary
directory are JIT compiled again and their result stored in memory; JIT
native code is run, then unloaded from memory

What I understood the other member to say, as well as the Wrox book, was
that the JIT native code created on the first call to MyPage1.aspx is stored
(in memory? on disk?) so that the next time you request MyPage1.aspx, it
will NOT JIT-compile those methods again, instead using the native code
already created. As you can see above, that is not my understanding; I
thought that the first call AND the second call to MyPage1.aspx would each
JIT compile needed methods out of the assembly. The only thing different
that happens on the first call to a page (MyPage2.aspx for example) is
compiling the .aspx file into an MSIL assembly and saving it on disk.

So, does the second call to the same page JIT compile parts of the MSIL
assembly to native code again, or does it only happen once--on the first
call to the page?

JIT Compilation
http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconjitcompilation.as
p
explains that the code is JIT'ed, then subsequent execution is based on the
JIT'ed code. Sure, if you call MyPage.aspx which uses the method MyMethod in
assembly MyClass.dll, MyMethod gets JIT'ed the first time so that if you
call MyMethod ten times in MyPage, then 9 of the calls will use the native
code version. But every time you call MyPage.aspx, that first call to
MyMethod will result in MyMethod getting JIT compiled to native code which
resides only in memory.

The same idea, it seems, applies to the MyPage1.aspx/MyPage2.aspx example
above. JIT-compiled native code is stored in memory for the duration of the
current page's request, THEN it is unloaded from memory. Each request for a
certain page requires a fresh JIT compilation for that page.

As I said, that's my understanding and interpretation of the documentation
I've read thus far. Since each page is a separate assembly, I assumed that
the JIT-compiled methods from that assembly would be unloaded from memory
once the IIS request for that page was fulfilled. (OR perhaps it would not,
since it's an in-process DLL and not an out-of-process EXE...)

Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfnativeimagegenerat
orngenexe.asp
says, "In version 1.0 of the common language runtime, there is no automatic
creation or deletion of native images. You must manually create and delete
all native images using Ngen.exe" where a native image is defined as "a file
containing compiled processor-specific machine code".

So it sounds like if the native code IS cached, it is not cached on disk. I
wouldn't be entirely surprised to find out that the native code compilation
sits in memory until IIS is stopped, the ASPX is replaced, or that memory is
needed.

Any clear information on this, especially from Microsoft, would be
appreciated!

Peter Johnson
ASPLists.com Moderation Team
Visit Peter's Professional ASP for Access advice and more!
http://www.aspalliance.com/PeterJohnson/

----------------------------------------------------------------------------

This e-mail and any attachments may be confidential or legally privileged.
If you received this message in error or are not the intended recipient, you
should destroy the e-mail message and any attachments or copies, and you are
prohibited from retaining, distributing, disclosing or using any information
contained herein. Please inform us of the erroneous delivery by return
e-mail.

Thank you for your cooperation.

----------------------------------------------------------------------------

Reply to this message...

Scott (VIP)

Here's the timing:

1. Machine boots
2. Request for MyPage.aspx comes in (first time)
3. MyPage.aspx compiles to an assembly (we'll call it MyPage.dll)
4. The portions of MyPage.dll that are needed for execution are JITed to
memory.
5. Page execution completed, JITed code stays in memory.
6. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.
7. The source for MyPage.aspx changes.
8. A new request for MyPage.aspx comes in. MyPage.aspx compiles to an
assembly and JITs, executes. The JITed code stays in memory.
9. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.
10. IIS it stoped and started.
11. New request for MyPage.aspx comes in. The page hasn't changed.
Because IIS stoped and started, the JITed code is no longer in memory.
The existing MyPage.dll JITs and executes.

That's my story, and I'm sticking to it :)

Scott Swigart
3 Leaf Solutions LLC
www.3leafsolutions.com
503-281-9681

-----Original Message-----
From: Johnson, Peter [mailto:Click here to reveal e-mail address]=20
Sent: Monday, August 20, 2001 3:35 PM
To: aspngfw
Subject: [aspngfw] NOT ANSWERED BEFORE: ASPX native code compilation
question

I asked this question Friday afternoon on these two list servers and got
no response. So here's another try: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There has been some confusion over when/how often ASPX pages are
compiled from their MSIL assemblies to native code. I've read other
members (on
aspngfreeforall) and books ("Introducing .NET" by Wrox) that seem to say
that native code is cached between page requests, and I've read/heard
that the assembly is JIT compiled to native code for each page request
(although the MSIL assembly is definitely cached). Information I've
gotten from Microsoft thus far via documentation, a webcast, and an
e-mail, has been ambiguous. So is the native code regenerated every time
the page is requested, or is it only JIT compiled once? This is a long
e-mail (necessarily because it's not a simple subject), so bear with me.

Let's say I create two ASP.NET pages called MyPage1.aspx and
MyPage2.aspx. I start the server (the physical machine and IIS), then
call each page twice. Here's what I understand to happen.
=20
MyPage1.aspx first call - ASP.NET ISAPI application is loaded, along
with CLR and supporting libraries/files; MyPage1.aspx is compiled to
MSIL assembly; MSIL assembly is saved in a temporary directory on disk;
needed methods in the MSIL assembly are JIT compiled and their result
stored in memory; JIT native code is run, then unloaded from memory
=20
MyPage1.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory
=20
MyPage2.aspx first call - MyPage2.aspx is compiled to MSIL assembly;
MSIL assembly is saved in a temporary directory on disk; needed methods
in the MSIL assembly are JIT compiled and their result stored in memory;
JIT native code is run, then unloaded from memory
=20
MyPage2.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory
=20
What I understood the other member to say, as well as the Wrox book, was
that the JIT native code created on the first call to MyPage1.aspx is
stored (in memory? on disk?) so that the next time you request
MyPage1.aspx, it will NOT JIT-compile those methods again, instead using
the native code already created. As you can see above, that is not my
understanding; I thought that the first call AND the second call to
MyPage1.aspx would each JIT compile needed methods out of the assembly.
The only thing different that happens on the first call to a page
(MyPage2.aspx for example) is compiling the .aspx file into an MSIL
assembly and saving it on disk.
=20
So, does the second call to the same page JIT compile parts of the MSIL
assembly to native code again, or does it only happen once--on the first
call to the page?
=20
JIT Compilation
http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconjitcompilatio
n.as
p
explains that the code is JIT'ed, then subsequent execution is based on
the JIT'ed code. Sure, if you call MyPage.aspx which uses the method
MyMethod in assembly MyClass.dll, MyMethod gets JIT'ed the first time so
that if you call MyMethod ten times in MyPage, then 9 of the calls will
use the native code version. But every time you call MyPage.aspx, that
first call to MyMethod will result in MyMethod getting JIT compiled to
native code which resides only in memory.
=20
The same idea, it seems, applies to the MyPage1.aspx/MyPage2.aspx
example above. JIT-compiled native code is stored in memory for the
duration of the current page's request, THEN it is unloaded from memory.
Each request for a certain page requires a fresh JIT compilation for
that page.
=20
As I said, that's my understanding and interpretation of the
documentation I've read thus far. Since each page is a separate
assembly, I assumed that the JIT-compiled methods from that assembly
would be unloaded from memory once the IIS request for that page was
fulfilled. (OR perhaps it would not, since it's an in-process DLL and
not an out-of-process EXE...)

Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfnativeimagegen
erat
orngenexe.asp
says, "In version 1.0 of the common language runtime, there is no
automatic creation or deletion of native images. You must manually
create and delete all native images using Ngen.exe" where a native image
is defined as "a file containing compiled processor-specific machine
code".

So it sounds like if the native code IS cached, it is not cached on
disk. I wouldn't be entirely surprised to find out that the native code
compilation sits in memory until IIS is stopped, the ASPX is replaced,
or that memory is needed.

Any clear information on this, especially from Microsoft, would be
appreciated!

Peter Johnson
ASPLists.com Moderation Team
Visit Peter's Professional ASP for Access advice and more!
http://www.aspalliance.com/PeterJohnson/

------------------------------------------------------------------------
----

This e-mail and any attachments may be confidential or legally
privileged. If you received this message in error or are not the
intended recipient, you should destroy the e-mail message and any
attachments or copies, and you are prohibited from retaining,
distributing, disclosing or using any information contained herein.
Please inform us of the erroneous delivery by return e-mail.=20

Thank you for your cooperation.

------------------------------------------------------------------------
----

| [aspngfw] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspngfw.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives

Reply to this message...

Paul D. Murphy

I'll take a stab at this but I'm not 100% sure that I'm absolutely
correct.=20
=20
First thing is that there are two methods by which an ASP.NET
application is compiled; either at run-time when the request comes in or
pre-compiled by an external compiler.
=20
When a page request comes in the ASP.NET engine scans the text in the
ASPX page and uses the markup to generate a class file specifically for
that page. This is not your code-behind class file. When this process
happens if the ASP.NET runtime determines that the event handling code
associated with the page has not been compiled, it attempts to wire up
the event hooks and generate that class into the assembly. If it can't
do it you get an exception. If that file already exists in the bin
directory then this doesn't happen, it uses the pre-compiled assembly.
Whether or not this assembly is cached, I'm not sure (don't think so
though). You can see this if you set a break point in visual studio and
step into the first line of the Init event of your page. Between the
Init event of the page and the load event of the page you will step into
a page with an obscure name like SJDL24S.cs. This page contains the
execution path for the control tree. This is the 'page' that actually
gets cached (I'm not sure about this point, either but think so).
=20
All of this happens on the first page call. In the second page call
nothing happens with the exception of the page executing according to
the execution path JIT'd the first time around.
=20
That's my understanding. If someone has a definitive answer I'd like to
know for sure.
=20
Paul
=20
=20
=20
=20

Reply to this message...

Scott Guthrie (VIP)

Scott's answer below is correct -- this is indeed what happens. Note
that the result of compilation -- an assembly with a .dll extension --
is persisted to disk and survives process restarts. As such, we don't
need to reparse or recompile .aspx pages across process restarts, and we
don't need to recompute or save metadata either.

However, the final act of JITing the IL assembly into native x86
instructions does re-occur everytime the process is restarted (note:
this only happens on the first request after a restart -- after that it
stays in memory).

Note that in practice the cost of dynamic JITing the first access of a
page's code is minimal. Because most of the overall page code path
actually lives within framework libraries (for example: the code within
the page base class, the code within System.Data, System.XML, etc) --
the number of instructions generated from your actual code are pretty
minimal. Because we can dynamically JIT millions of instructions to
native code per second, this one time cost ends up being noise in the
grand scheme of things.

Hope this helps,

Scott

-----Original Message-----
From: Scott [mailto:Click here to reveal e-mail address]=20
Sent: Monday, August 20, 2001 5:07 PM
To: aspngfw
Subject: [aspngfw] RE: NOT ANSWERED BEFORE: ASPX native code compilation
question

Here's the timing:

1. Machine boots

2. Request for MyPage.aspx comes in (first time)

3. MyPage.aspx compiles to an assembly (we'll call it MyPage.dll)=20

4. The portions of MyPage.dll that are needed for execution are JITed to
memory.=20

5. Page execution completed, JITed code stays in memory.=20

6. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.=20

7. The source for MyPage.aspx changes.=20

8. A new request for MyPage.aspx comes in. MyPage.aspx compiles to an
assembly and JITs, executes. The JITed code stays in memory.=20

9. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.=20

10. IIS it stoped and started. 11. New request for MyPage.aspx comes in.
The page hasn't changed. Because IIS stoped and started, the JITed code
is no longer in memory. The existing MyPage.dll JITs and executes.

That's my story, and I'm sticking to it :)

Scott Swigart
3 Leaf Solutions LLC
www.3leafsolutions.com
503-281-9681

-----Original Message-----
From: Johnson, Peter [mailto:Click here to reveal e-mail address]=20
Sent: Monday, August 20, 2001 3:35 PM
To: aspngfw
Subject: [aspngfw] NOT ANSWERED BEFORE: ASPX native code compilation
question

I asked this question Friday afternoon on these two list servers and got
no response. So here's another try: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There has been some confusion over when/how often ASPX pages are
compiled from their MSIL assemblies to native code. I've read other
members (on
aspngfreeforall) and books ("Introducing .NET" by Wrox) that seem to say
that native code is cached between page requests, and I've read/heard
that the assembly is JIT compiled to native code for each page request
(although the MSIL assembly is definitely cached). Information I've
gotten from Microsoft thus far via documentation, a webcast, and an
e-mail, has been ambiguous. So is the native code regenerated every time
the page is requested, or is it only JIT compiled once? This is a long
e-mail (necessarily because it's not a simple subject), so bear with me.

Let's say I create two ASP.NET pages called MyPage1.aspx and
MyPage2.aspx. I start the server (the physical machine and IIS), then
call each page twice. Here's what I understand to happen.
=20
MyPage1.aspx first call - ASP.NET ISAPI application is loaded, along
with CLR and supporting libraries/files; MyPage1.aspx is compiled to
MSIL assembly; MSIL assembly is saved in a temporary directory on disk;
needed methods in the MSIL assembly are JIT compiled and their result
stored in memory; JIT native code is run, then unloaded from memory
=20
MyPage1.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory
=20
MyPage2.aspx first call - MyPage2.aspx is compiled to MSIL assembly;
MSIL assembly is saved in a temporary directory on disk; needed methods
in the MSIL assembly are JIT compiled and their result stored in memory;
JIT native code is run, then unloaded from memory
=20
MyPage2.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory
=20
What I understood the other member to say, as well as the Wrox book, was
that the JIT native code created on the first call to MyPage1.aspx is
stored (in memory? on disk?) so that the next time you request
MyPage1.aspx, it will NOT JIT-compile those methods again, instead using
the native code already created. As you can see above, that is not my
understanding; I thought that the first call AND the second call to
MyPage1.aspx would each JIT compile needed methods out of the assembly.
The only thing different that happens on the first call to a page
(MyPage2.aspx for example) is compiling the .aspx file into an MSIL
assembly and saving it on disk.
=20
So, does the second call to the same page JIT compile parts of the MSIL
assembly to native code again, or does it only happen once--on the first
call to the page?
=20
JIT Compilation
http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconjitcompilatio
n.as
p
explains that the code is JIT'ed, then subsequent execution is based on
the JIT'ed code. Sure, if you call MyPage.aspx which uses the method
MyMethod in assembly MyClass.dll, MyMethod gets JIT'ed the first time so
that if you call MyMethod ten times in MyPage, then 9 of the calls will
use the native code version. But every time you call MyPage.aspx, that
first call to MyMethod will result in MyMethod getting JIT compiled to
native code which resides only in memory.
=20
The same idea, it seems, applies to the MyPage1.aspx/MyPage2.aspx
example above. JIT-compiled native code is stored in memory for the
duration of the current page's request, THEN it is unloaded from memory.
Each request for a certain page requires a fresh JIT compilation for
that page.
=20
As I said, that's my understanding and interpretation of the
documentation I've read thus far. Since each page is a separate
assembly, I assumed that the JIT-compiled methods from that assembly
would be unloaded from memory once the IIS request for that page was
fulfilled. (OR perhaps it would not, since it's an in-process DLL and
not an out-of-process EXE...)

Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfnativeimagegen
erat
orngenexe.asp
says, "In version 1.0 of the common language runtime, there is no
automatic creation or deletion of native images. You must manually
create and delete all native images using Ngen.exe" where a native image
is defined as "a file containing compiled processor-specific machine
code".

So it sounds like if the native code IS cached, it is not cached on
disk. I wouldn't be entirely surprised to find out that the native code
compilation sits in memory until IIS is stopped, the ASPX is replaced,
or that memory is needed.

Any clear information on this, especially from Microsoft, would be
appreciated!

Peter Johnson
ASPLists.com Moderation Team
Visit Peter's Professional ASP for Access advice and more!
http://www.aspalliance.com/PeterJohnson/

------------------------------------------------------------------------
----

This e-mail and any attachments may be confidential or legally
privileged. If you received this message in error or are not the
intended recipient, you should destroy the e-mail message and any
attachments or copies, and you are prohibited from retaining,
distributing, disclosing or using any information contained herein.
Please inform us of the erroneous delivery by return e-mail.=20

Thank you for your cooperation.

------------------------------------------------------------------------
----

| [aspngfw] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives

| [aspngfw] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives

Reply to this message...

Hank Meyne

Here goes:

If you are using C# for example, and you have inline script (without your
own code-behind class), ASP.NET does the following:

1) writes a C# class for you the first time the page is requested or has
changed.

2) compiles the new class using csc.

3) the new .dll file is then JIT ed into x86 code and cached.

You can look at the C# source file that ASP.NET creates for you. These temp
files are: /Winnt/Microsoft.NET/Framework/v{version number}/Temporary
ASP.NET Files, which can be changed via the tempDirectory attribute of the
<compilation> tag in Web.config.

Under this folder, is a new folder (one for every ASP.NET app on your
server) with a weird named folder under it, which is named by a hash
algorithm that MS uses. Here are all of the temporary files that ASP.NET
creates for the app in question.

The .cs file that was created for the inline script page is located in this
folder, and will also be named with a wierd hash code as well.

The class in this file inherits directly from System.Web.UI.Page and the
System.Web.SessionState.IRequiresSessionState interface. The class will be
names <pagename>_aspx, which is excactly what you would see if you run this
code in a ASP.NET page:
this.GetType().ToString();

Any un-named server side controls in your page will be named by ASP.NET
something like:
protected System.Web.UI.WebControls.Button __control3;

Any controls you name yourself will keep that name.

So, your page with in-line script will be compiled not unlike we would do
ourselves, or VSN would do. At that point, it is in memory and ready to be
run by the aspnet_wp.exe (or aspnet_ewp.exe) service, which is the CLR host
for web pages in .NET.

(Credit goes to Scott S. Davis for figuring out most of this in the first
place!)

If anything I said is wrong, please post the truth!

Hank Meyne

-----Original Message-----
From: Scott [mailto:Click here to reveal e-mail address]
Sent: Monday, August 20, 2001 8:07 PM
To: aspngfw
Subject: [aspngfw] RE: NOT ANSWERED BEFORE: ASPX native code compilation
question

Here's the timing:

1. Machine boots
2. Request for MyPage.aspx comes in (first time)
3. MyPage.aspx compiles to an assembly (we'll call it MyPage.dll)
4. The portions of MyPage.dll that are needed for execution are JITed to
memory.
5. Page execution completed, JITed code stays in memory.
6. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.
7. The source for MyPage.aspx changes.
8. A new request for MyPage.aspx comes in. MyPage.aspx compiles to an
assembly and JITs, executes. The JITed code stays in memory.
9. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.
10. IIS it stoped and started.
11. New request for MyPage.aspx comes in. The page hasn't changed.
Because IIS stoped and started, the JITed code is no longer in memory.
The existing MyPage.dll JITs and executes.

That's my story, and I'm sticking to it :)

Scott Swigart
3 Leaf Solutions LLC
www.3leafsolutions.com
503-281-9681

-----Original Message-----
From: Johnson, Peter [mailto:Click here to reveal e-mail address]
Sent: Monday, August 20, 2001 3:35 PM
To: aspngfw
Subject: [aspngfw] NOT ANSWERED BEFORE: ASPX native code compilation
question

I asked this question Friday afternoon on these two list servers and got
no response. So here's another try: ==========

There has been some confusion over when/how often ASPX pages are
compiled from their MSIL assemblies to native code. I've read other
members (on
aspngfreeforall) and books ("Introducing .NET" by Wrox) that seem to say
that native code is cached between page requests, and I've read/heard
that the assembly is JIT compiled to native code for each page request
(although the MSIL assembly is definitely cached). Information I've
gotten from Microsoft thus far via documentation, a webcast, and an
e-mail, has been ambiguous. So is the native code regenerated every time
the page is requested, or is it only JIT compiled once? This is a long
e-mail (necessarily because it's not a simple subject), so bear with me.

Let's say I create two ASP.NET pages called MyPage1.aspx and
MyPage2.aspx. I start the server (the physical machine and IIS), then
call each page twice. Here's what I understand to happen.

MyPage1.aspx first call - ASP.NET ISAPI application is loaded, along
with CLR and supporting libraries/files; MyPage1.aspx is compiled to
MSIL assembly; MSIL assembly is saved in a temporary directory on disk;
needed methods in the MSIL assembly are JIT compiled and their result
stored in memory; JIT native code is run, then unloaded from memory

MyPage1.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory

MyPage2.aspx first call - MyPage2.aspx is compiled to MSIL assembly;
MSIL assembly is saved in a temporary directory on disk; needed methods
in the MSIL assembly are JIT compiled and their result stored in memory;
JIT native code is run, then unloaded from memory

MyPage2.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory

What I understood the other member to say, as well as the Wrox book, was
that the JIT native code created on the first call to MyPage1.aspx is
stored (in memory? on disk?) so that the next time you request
MyPage1.aspx, it will NOT JIT-compile those methods again, instead using
the native code already created. As you can see above, that is not my
understanding; I thought that the first call AND the second call to
MyPage1.aspx would each JIT compile needed methods out of the assembly.
The only thing different that happens on the first call to a page
(MyPage2.aspx for example) is compiling the .aspx file into an MSIL
assembly and saving it on disk.

So, does the second call to the same page JIT compile parts of the MSIL
assembly to native code again, or does it only happen once--on the first
call to the page?

JIT Compilation
http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconjitcompilatio
n.as
p
explains that the code is JIT'ed, then subsequent execution is based on
the JIT'ed code. Sure, if you call MyPage.aspx which uses the method
MyMethod in assembly MyClass.dll, MyMethod gets JIT'ed the first time so
that if you call MyMethod ten times in MyPage, then 9 of the calls will
use the native code version. But every time you call MyPage.aspx, that
first call to MyMethod will result in MyMethod getting JIT compiled to
native code which resides only in memory.

The same idea, it seems, applies to the MyPage1.aspx/MyPage2.aspx
example above. JIT-compiled native code is stored in memory for the
duration of the current page's request, THEN it is unloaded from memory.
Each request for a certain page requires a fresh JIT compilation for
that page.

As I said, that's my understanding and interpretation of the
documentation I've read thus far. Since each page is a separate
assembly, I assumed that the JIT-compiled methods from that assembly
would be unloaded from memory once the IIS request for that page was
fulfilled. (OR perhaps it would not, since it's an in-process DLL and
not an out-of-process EXE...)

Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfnativeimagegen
erat
orngenexe.asp
says, "In version 1.0 of the common language runtime, there is no
automatic creation or deletion of native images. You must manually
create and delete all native images using Ngen.exe" where a native image
is defined as "a file containing compiled processor-specific machine
code".

So it sounds like if the native code IS cached, it is not cached on
disk. I wouldn't be entirely surprised to find out that the native code
compilation sits in memory until IIS is stopped, the ASPX is replaced,
or that memory is needed.

Any clear information on this, especially from Microsoft, would be
appreciated!

Peter Johnson
ASPLists.com Moderation Team
Visit Peter's Professional ASP for Access advice and more!
http://www.aspalliance.com/PeterJohnson/

------------------------------------------------------------------------
----

This e-mail and any attachments may be confidential or legally
privileged. If you received this message in error or are not the
intended recipient, you should destroy the e-mail message and any
attachments or copies, and you are prohibited from retaining,
distributing, disclosing or using any information contained herein.
Please inform us of the erroneous delivery by return e-mail.

Thank you for your cooperation.

------------------------------------------------------------------------
----

| [aspngfw] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives

| [aspngfw] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives

Reply to this message...

Mike Amundsen

thanks to *both* scotts for helping put this into perspective.

IMHO, as .NET moves to the reality stage, this series of events will become
the subject of much urban legend unless we all payclose attention to the
details and all pass this info to the 'masses' just starting to kick the
tires on .NET.

thanks

MCA

"Scott Guthrie" <Click here to reveal e-mail address> wrote in message
news:464712@aspngfw...

Scott's answer below is correct -- this is indeed what happens. Note
that the result of compilation -- an assembly with a .dll extension --
is persisted to disk and survives process restarts. As such, we don't
need to reparse or recompile .aspx pages across process restarts, and we
don't need to recompute or save metadata either.

However, the final act of JITing the IL assembly into native x86
instructions does re-occur everytime the process is restarted (note:
this only happens on the first request after a restart -- after that it
stays in memory).

Note that in practice the cost of dynamic JITing the first access of a
page's code is minimal. Because most of the overall page code path
actually lives within framework libraries (for example: the code within
the page base class, the code within System.Data, System.XML, etc) --
the number of instructions generated from your actual code are pretty
minimal. Because we can dynamically JIT millions of instructions to
native code per second, this one time cost ends up being noise in the
grand scheme of things.

Hope this helps,

Scott

-----Original Message-----
From: Scott [mailto:Click here to reveal e-mail address]
Sent: Monday, August 20, 2001 5:07 PM
To: aspngfw
Subject: [aspngfw] RE: NOT ANSWERED BEFORE: ASPX native code compilation
question

Here's the timing:

1. Machine boots

2. Request for MyPage.aspx comes in (first time)

3. MyPage.aspx compiles to an assembly (we'll call it MyPage.dll)

4. The portions of MyPage.dll that are needed for execution are JITed to
memory.

5. Page execution completed, JITed code stays in memory.

6. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.

7. The source for MyPage.aspx changes.

8. A new request for MyPage.aspx comes in. MyPage.aspx compiles to an
assembly and JITs, executes. The JITed code stays in memory.

9. New request for MyPage.aspx comes in. The page hasn't changed. The
JITed code that is still in memory runs.

10. IIS it stoped and started. 11. New request for MyPage.aspx comes in.
The page hasn't changed. Because IIS stoped and started, the JITed code
is no longer in memory. The existing MyPage.dll JITs and executes.

That's my story, and I'm sticking to it :)

Scott Swigart
3 Leaf Solutions LLC
www.3leafsolutions.com
503-281-9681

-----Original Message-----
From: Johnson, Peter [mailto:Click here to reveal e-mail address]
Sent: Monday, August 20, 2001 3:35 PM
To: aspngfw
Subject: [aspngfw] NOT ANSWERED BEFORE: ASPX native code compilation
question

I asked this question Friday afternoon on these two list servers and got
no response. So here's another try: ==========

There has been some confusion over when/how often ASPX pages are
compiled from their MSIL assemblies to native code. I've read other
members (on
aspngfreeforall) and books ("Introducing .NET" by Wrox) that seem to say
that native code is cached between page requests, and I've read/heard
that the assembly is JIT compiled to native code for each page request
(although the MSIL assembly is definitely cached). Information I've
gotten from Microsoft thus far via documentation, a webcast, and an
e-mail, has been ambiguous. So is the native code regenerated every time
the page is requested, or is it only JIT compiled once? This is a long
e-mail (necessarily because it's not a simple subject), so bear with me.

Let's say I create two ASP.NET pages called MyPage1.aspx and
MyPage2.aspx. I start the server (the physical machine and IIS), then
call each page twice. Here's what I understand to happen.

MyPage1.aspx first call - ASP.NET ISAPI application is loaded, along
with CLR and supporting libraries/files; MyPage1.aspx is compiled to
MSIL assembly; MSIL assembly is saved in a temporary directory on disk;
needed methods in the MSIL assembly are JIT compiled and their result
stored in memory; JIT native code is run, then unloaded from memory

MyPage1.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory

MyPage2.aspx first call - MyPage2.aspx is compiled to MSIL assembly;
MSIL assembly is saved in a temporary directory on disk; needed methods
in the MSIL assembly are JIT compiled and their result stored in memory;
JIT native code is run, then unloaded from memory

MyPage2.aspx second call - needed methods in the MSIL assembly in
temporary directory are JIT compiled again and their result stored in
memory; JIT native code is run, then unloaded from memory

What I understood the other member to say, as well as the Wrox book, was
that the JIT native code created on the first call to MyPage1.aspx is
stored (in memory? on disk?) so that the next time you request
MyPage1.aspx, it will NOT JIT-compile those methods again, instead using
the native code already created. As you can see above, that is not my
understanding; I thought that the first call AND the second call to
MyPage1.aspx would each JIT compile needed methods out of the assembly.
The only thing different that happens on the first call to a page
(MyPage2.aspx for example) is compiling the .aspx file into an MSIL
assembly and saving it on disk.

So, does the second call to the same page JIT compile parts of the MSIL
assembly to native code again, or does it only happen once--on the first
call to the page?

JIT Compilation
http://msdn.microsoft.com/library/en-us/cpguidnf/html/cpconjitcompilatio
n.as
p
explains that the code is JIT'ed, then subsequent execution is based on
the JIT'ed code. Sure, if you call MyPage.aspx which uses the method
MyMethod in assembly MyClass.dll, MyMethod gets JIT'ed the first time so
that if you call MyMethod ten times in MyPage, then 9 of the calls will
use the native code version. But every time you call MyPage.aspx, that
first call to MyMethod will result in MyMethod getting JIT compiled to
native code which resides only in memory.

The same idea, it seems, applies to the MyPage1.aspx/MyPage2.aspx
example above. JIT-compiled native code is stored in memory for the
duration of the current page's request, THEN it is unloaded from memory.
Each request for a certain page requires a fresh JIT compilation for
that page.

As I said, that's my understanding and interpretation of the
documentation I've read thus far. Since each page is a separate
assembly, I assumed that the JIT-compiled methods from that assembly
would be unloaded from memory once the IIS request for that page was
fulfilled. (OR perhaps it would not, since it's an in-process DLL and
not an out-of-process EXE...)

Native Image Generator (Ngen.exe)
http://msdn.microsoft.com/library/en-us/cptools/html/cpgrfnativeimagegen
erat
orngenexe.asp
says, "In version 1.0 of the common language runtime, there is no
automatic creation or deletion of native images. You must manually
create and delete all native images using Ngen.exe" where a native image
is defined as "a file containing compiled processor-specific machine
code".

So it sounds like if the native code IS cached, it is not cached on
disk. I wouldn't be entirely surprised to find out that the native code
compilation sits in memory until IIS is stopped, the ASPX is replaced,
or that memory is needed.

Any clear information on this, especially from Microsoft, would be
appreciated!

Peter Johnson
ASPLists.com Moderation Team
Visit Peter's Professional ASP for Access advice and more!
http://www.aspalliance.com/PeterJohnson/

------------------------------------------------------------------------
----

This e-mail and any attachments may be confidential or legally
privileged. If you received this message in error or are not the
intended recipient, you should destroy the e-mail message and any
attachments or copies, and you are prohibited from retaining,
distributing, disclosing or using any information contained herein.
Please inform us of the erroneous delivery by return e-mail.

Thank you for your cooperation.

------------------------------------------------------------------------
----

| [aspngfw] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives

| [aspngfw] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngfw.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives

Reply to this message...

	System.Web.SessionState.IRequiresSessionState
	System.Web.UI.Page
	System.Web.UI.WebControls.Button

ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification

Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews

.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT

Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project

FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.

Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials

	Copyright © ExamGuru, Inc. 2001-2006
	Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification