1 / 27

Lecture 4: J# Execution Model

Lecture 4: J# Execution Model. Objectives. “J# programs execute like any other .NET program --- based on a run-time execution engine and an extensive software library. The details of how this works is quite interesting, and exemplifies how program execution has evolved... ”

samson
Download Presentation

Lecture 4: J# Execution Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 4:J# Execution Model

  2. Objectives “J# programs execute like any other .NET program --- based on a run-time execution engine and an extensive software library. The details of how this works is quite interesting, and exemplifies how program execution has evolved... ” • .NET execution model • J# execution model

  3. Part 1 • .NET execution model…

  4. transactions.txt Banking App customers.txt Example • Recall the Banking App we built…

  5. Visual Studio .NET BankingApp.exe BankingApp.exe • Visual Studio .NET produces .EXE: App.jsl Customer.jsl CustomersIO.jsl Transactions.jsl

  6. How does .EXE execute? • Since you can double-click on .EXE, you might be mislead… • Recall the .NET architecture: • run-time environment + large software library BankingApp.exe .NET FrameworkClass Library (FxCL) Common Language Runtime (CLR) Operating System Hardware

  7. .NET execution model • When you run .EXE, a process is created & a small main() run • main() loads CLR into process & starts CLR running • CLR then loads our .NET code & begins execution… BankingApp.exe process BankingApp code CLR FxCL Operating System Hardware

  8. Why do this? • As noted in Lecture 1, two reasons: • safer execution • portable execution • Safer? • because CLR can prevent BankingApp from doing things it doesn't have permission to do • Portable? • because BankingApp code can run anywhere CLR exists

  9. Are .NET programs really portable? • Yes! • Implementations exist on: • FreeBSD (i.e. the OS underneath Mac OS X) • Linux (Mono project) • Unix (dotGNU project) • Unfortunately, support for J# is lagging, mostly C# and VB at the moment…

  10. What do compiled .NET programs look like? • Java programs are compiled into bytecodes for portability • .NET programs are compiled into CIL for portability • CIL = Common Intermediate Language • a portable, generic assembly language…

  11. JIT Compiler How does CLR execute CIL? • CIL cannot be directly executed on the hardware • CIL is translated at run-time into hardware's object code • this is know as Just-In-Time ("JIT") compilation BankingApp.exe process BankingApp code CLR FxCL object code Operating System Hardware

  12. Part 2 • J# execution model…

  13. Where's the Java Class Library? • J# enables the best of both worlds: • you can use Java to program the .NET platform (i.e. FxCL) • you can use Java to program the Java platform (i.e. JCL) • So far, we've only shown the FxCL: • where is the Java Class Library? • how is it represented? • how is it found?

  14. (1) Where is the JCL? • The JCL is considered part of the .NET Framework Class Library • in other words, it has been rewritten by Microsoft for .NET • compatible with Sun's JCL, but not a complete implementation: • most of v1.1, some of v1.2 • full support for portion of JCL required by AP CS BankingApp.exe process BankingApp code CLR FxCL JCL

  15. (2) How is the JCL represented? • Java uses .class & .jar files • The .NET Framework Class Library is a set of .DLLs • DLL = Dynamic Link Library file • DLL = compiled code in library form, loaded & linked at run-time • 1 DLL typically contains multiple classes • Windows OS itself is built from 100's of DLLs • The JCL is a subset of the FxCL .DLLs: • vjscor.dll • vjslib.dll • VJSSupUILib.dll • … FxCL vjscor.dll vjslib.dll VJSSupUILib.dll . . .

  16. (3) How is the JCL found? • Java searches along a CLASSPATH (list) of directories • J# searches exactly 2 places, in this order: • GAC: Global Assembly Cache (a Windows OS directory) • AppBase: directory containing .EXE file

  17. The GAC • The GAC is a global repository of .NET DLLs • .NET DLLs are known as "assemblies", hence the term assembly cache • GAC is a protected Windows OS directory • created when .NET is installed • any user can read from cache • requires administrative rights to modify • Location? • Windows XP: C:\Windows\Assembly • Windows 2000: C:\WinNT\Assembly

  18. Views of the GAC • Explorer shows you conceptual view • For actual representation, open command prompt & cd to it: C:\> cd Windows C:\Windows\> cd Assembly C:\Windows\Assembly> dir 04/20/2004 <DIR> GAC 04/20/2004 <DIR> NativeImages1_v1.0.3705 04/20/2004 <DIR> NativeImages1_v1.1.4322 04/20/2004 <DIR> temp C:\Windows\Assembly> cd GAC C:\Windows\Assembly\GAC> cd vjscor C:\Windows\Assembly\GAC\vjscor> cd 1.0.5* C:\Windows\Assembly\GAC\vjscor\1.0.5…> dir 04/20/2004 8,704 vjscor.dll

  19. One last piece of the puzzle... • When you run .EXE file… • … how does CLR know exactly which DLLs to load? ? BankingApp.exe process BankingApp code FxCL vjscor.dll vjslib.dll CLR VJSSupUILib.dll

  20. .DLL dependencies stored in .EXE • .EXE contains a list of dependencies, as well as code…

  21. How did dependencies end up in .EXE? • Visual Studio .NET! • Visual Studio compiles dependency information into .EXE • based on list of references maintained in project file… • Every .DLL must be explicitly referenced • common references set for youautomatically by VS .NET • additional references are addedvia Project menu, Add Reference…

  22. ILDasm • ILDasm = "IL Disassembler" • ILDasm allows you to reverse engineer .EXE / .DLL • to see manifest, CIL, etc. • ILDasm is a command-line tool • installed as part of Visual Studio .NET • to run, use Visual Studio .NET2003 Command Prompt C:\BankingApp\bin\Debug> ildasm BankingApp.exe

  23. Overlap between JCL and FxCL • There is some overlap between Java Class Library and the .NET Framework Class Library, which can cause confusion. • Consider the different implementations of ArrayList, each with its own method for finding the size:

  24. ILDasm to see ArrayList size() • For instance see the String methods using Intellisense. Both the JCL equals() and the FxCL Equals()are shown. • Consider the implementation of ArrayList size() • Open a Visual Studio Command Prompt(Start / Visual Studio / Tools / Command Prompt) • Navigate to the GAC:C:/Windows / Assembly / GAC • Enter the vjslib directory, then into the version directory cd vjslib cd 1.0.5* • Look at the contents of vjslib.dll using ILDasm:ildasm vjslib.dll

  25. ILDasm to see ArrayList size() (cont'd) • Select java.util • Drill down to locate java.util.ArrayList • Note how the size()method is implemented

  26. Summary • J# is Java on the .NET platform • full support for .NET Framework Class Library • partial support for Java Class Library • J# has a different execution model than Java • Java uses JVM, searches for .class/.jar files along CLASSPATH • J# uses CLR, searches for .DLL files in GAC & AppBase

  27. What's next? • Lab #2…

More Related