• Save
JAVA, JVM, JAVA Understanding, JDBC,
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


JAVA, JVM, JAVA Understanding, JDBC,



JAVA training by Synergetics Trainer Omprakash Pandey, for more information please visit: http://www.synergetics-india.com/

JAVA training by Synergetics Trainer Omprakash Pandey, for more information please visit: http://www.synergetics-india.com/



Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.linkedin.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Hello sir, please send me this file to my id nbhosale34@gmail.com...thanks in advance
    Are you sure you want to
    Your message goes here
  • plz mail this slide on yadav_tarun21@yahoo.in
    Are you sure you want to
    Your message goes here
  • so good..sir,could you please send me this presentation to my mail naresh.thanniru594@gmail.com
    Are you sure you want to
    Your message goes here
  • Great slides! Thanks for sharing!
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Instructor Notes
  • The role of the JVM can be viewed as a black box, where we are not interested on how it is implemented but rather on what does it do. The JVM reads a class file, which contains a series of JVM instructions, and then it translates these instructions into machine specific code. Compiled code to be executed by the Java virtual machine is represented using a hardware- and operating system-independent binary format, typically (but not necessarily) stored in a file, known as the class file format. The class file format precisely defines the representation of a class or interface, including details such as byte ordering that might be taken for granted in a platform-specific object file format. As a black-box, we can appreciate the JVM external relationship with the bytecodes and the underlying operating system.
  • http://ils.unc.edu/blaze/java/javahist.html January 15, 1991 "Stealth Project" (as named by Scott McNealy) brainstorming meeting in Aspen with Bill Joy, Andy Bechtolsheim, Wayne Rosing, Mike Sheridan, James Gosling and Patrick Naughton. September 16, 1994 Jonathon Payne and Naughton start writing "WebRunner," a Mosaic-like browser later renamed "HotJava" Autumn, 1994 Van Hoff implements Java compiler in Java. (Gosling had previously implemented it in C.) May 23, 1995 Sun formally announces Java and HotJava at SunWorld '95.
  • You express the program in source files written in the Java programming language, compile the source to Java class files, and run the class files on a Java virtual machine. When you write your program, you access system resources (such as I/O, for example) by calling methods in the classes that implement the Java Application Programming Interface, or Java API. As your program runs, it fulfills your program's Java API calls by invoking methods in class files that implement the Java API.
  • The abstract specification defines the behavior of an execution engine in terms of the instruction set. Concrete implementations, which may use a variety of techniques, are either software, hardware, or a combination of both. A runtime instance of an execution engine is a thread. Each thread of a running Java application is a distinct instance of the virtual machine's execution engine. From the beginning of its lifetime to the end, a thread is either executing bytecodes or native methods. A thread may execute bytecodes directly, by interpreting or executing natively in silicon, or indirectly as shown later, by just- in-time compiling and executing the resulting native code. A Java virtual machine implementation may use other threads invisible to the running application, such as a thread that performs garbage collection. Such threads need not be "instances" of the implementation's execution engine. All threads that belong to the running application, however, are execution engines in action.
  • In the Java virtual machine specification, the behavior of a virtual machine instance is described in terms of subsystems, memory areas, data types, and instructions. These components describe an abstract inner architecture for the abstract Java virtual machine. The purpose of these components is not so much to dictate an inner architecture for implementations. It is more to provide a way to strictly define the external behavior of implementations. The specification defines the required behavior of any Java virtual machine implementation in terms of these abstract components and their interactions. Each Java virtual machine has a class loader subsystem : a mechanism for loading types (classes and interfaces) given fully qualified names. Each Java virtual machine also has an execution engine : a mechanism responsible for executing the instructions contained in the methods of loaded classes. The Java virtual machine defines various runtime data areas that are used during execution of a program. Some of these data areas are created on Java virtual machine start-up and are destroyed only when the Java virtual machine exits. Other data areas are per thread. Per-thread data areas are created when a thread is created and destroyed when the thread exits. The pc registers Each Java virtual machine thread has its own pc (program counter) register. At any point, each Java virtual machine thread is executing the code of a single method, the current method for that thread. If that method is not native , the pc register contains the address of the Java virtual machine instruction currently being executed. If the method currently being executed by the thread is native , the value of the Java virtual machine's pc register is undefined. Method area and heap Some runtime data areas are shared among all of an application's threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap . These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap. Java stacks Each Java virtual machine thread has a private Java virtual machine stack , created at the same time as the thread. The Java virtual stack stack is composed of stack frames (or frames ). A stack frame contains the state of one Java method invocation. When a thread invokes a method, the Java virtual machine pushes a new frame onto that thread's JVM stack. When the method completes, the virtual machine pops and discards the frame for that method.
  • Instructor Notes Different implementations of the virtual machine can have very different memory constraints. Some implementations may have a lot of memory in which to work, others may have very little. Some implementations may be able to take advantage of virtual memory, others may not. The abstract nature of the specification of the runtime data areas helps make it easier to implement the Java virtual machine on a wide variety of computers and devices. Some runtime data areas are shared among all of an application's threads and others are unique to individual threads. Each instance of the Java virtual machine has one method area and one heap . These areas are shared by all threads running inside the virtual machine. When the virtual machine loads a class file, it parses information about a type from the binary data contained in the class file. It places this type information into the method area. As the program runs, the virtual machine places all objects the program instantiates onto the heap. See Figure 5-2 for a graphical depiction of these memory areas.
  • Instructor Notes Java Virtual Machine implementations must be able to recognize and load classes and interfaces stored in binary files that conform to the Java class file format. An implementation is free to recognize other binary forms besides class files, but it must recognize class files. One example of an alternative binary format recognized by a particular Java Virtual Machine implementation is the CAB file. This file format, which is an archive of class files and other data files, is defined by Microsoft and recognized by their implementation of the Java Virtual Machine.
  • The class data sharing feature is aimed at reducing application startup time and footprint. The installation process loads a set of classes from the system jar file into a private, internal representation, then dumps that representation to a "shared archive" file. During subsequent JVM invocations, the shared archive is memory-mapped in, saving the cost of loading those classes and allowing much of the JVM's metadata for these classes to be shared among multiple JVM processes. The parallel collector has been enhanced to monitor and adapt to the memory needs of the application. You can specify performance goals for applications and the JVM will tune the size of the Java heap to meet those performance goals with the smallest application footprint consistent with those goals. The goal of this adaptive policy is to eliminate the need to tune command-line options to achieve the best performance. For a synopsis of garbage collection features, click the above link. At application startup, the launcher can attempt to detect whether the application is running on a "server-class" machine.

JAVA, JVM, JAVA Understanding, JDBC, Presentation Transcript

  • 1. Understanding JVM By Omprakash Pandey – Synergetics http://www.synergetics-india.com/
  • 2. JVM Introduction
    • Runtime Environment needed for executing class files
    • JRE = JVM + rt.jar
    • Enhancements needed in terms of JIT compiler and Class Data Sharing
    • JVM important functions and modules
  • 3. JVM Architecture: External Relationship
    • javac Greetings.java
    • Generates the Greetings.class file
    • java Greetings ”Hello Class”
    • Invokes a JVM implementation
    • Hello Class
    • OS displays message to
    • terminal
    • Class file
    JVM Platform
  • 4. JVM and other platforms
  • 5. JVM Evolution
    • Interpreter
      • Kaffe
      • Jupiter JVM
    • Just-In-Timer (JIT) compiler
      • IBM Java JIT compiler
    • Adaptive Optimization
      • HotSpot JVM
      • Jalapeno JVM
  • 6. Versions of Java
    • Oak (1991): Designed for embedded devices
    • Java (1995): Original version (had applets)
    • Java 1.1 (1997): Adds inner classes and a completely
    • new event-handling model
    • Java 1.2 (1998): Includes “Swing” but no new syntax
    • Java 1.3 (2000): Additional methods and packages, but no new syntax
    • Java 1.4 (2002): More additions and the assert statement
    • Java 1.5 (2004): Generics, enum s, new for loop, and other new syntax
    Java 1 Java 2 Java 5.0
  • 7. Prasad cs884 java.applet, java.awt, java.io, java.lang, java.net, java.util java.math, java.rmi, java.security, java.sql, java.text, java.beans javax.accessibility, javax.swing, org.omg javax.naming, javax.sound, javax.transaction java.nio, javax.imageio, javax.net, javax.print, javax.security, org.w3c javax.activity, javax. management Java 1.0 8 packages 212 classes Java 1.1 23 packages 504 classes Java 1.2 59 packages 1520 classes Java 1.3 77 packages 1595 classes Java 1.4 103 packages 2175 classes Java 1.5 131 packages 2656 classes New Events Inner class Object Serialization Jar Files International Reflection JDBC RMI JFC/Swing Drag and Drop Java2D CORBA JNDI Java Sound Timer Regular Exp Logging Assertions NIO
  • 8. JVM Working
  • 9. JVM Architecture: Execution Engine
    • Execution engine is at the core of JVM
    • Execution engine can be viewed in three senses
      • Abstract specification
      • Concrete implementation
      • Run-time instance
  • 10. Java Application Code Pluggable components that dynamically load into the virtual machine Calls to C Libraries JavaSE 6 Operating System Native Applications Java Application Code OS-Specific Calls Virtual Machine Java SE 5 Garbage collector Interpreter Exception handler Class loader Thread Model JVM Profiler Debugger Realtime Profiler Port Library (file IO, sockets, memory allocation, etc.) Uses 1 of many possible configurations JCL Natives JNI CDC MIDP Java calls JNI JIT CLDC Class Library JNI = Java Native Interface
  • 11. JVM Architecture: Internal Structure
  • 12. JVM Internals
  • 13. JVM Internal Threads
  • 14. Understanding Heap Sizes
    • GC resizes heap based on occupancy and duration stats
    • Occupancy Constraint:
    • 30%* < free < 60%* -Xminf < free < -Xmaxf
    • Duration Constraint:
    • 5%* < duration < 13%* -Xmint < duration < -Xmaxt
    • Adjustment Size:
    • 1Mb* < adjustment < ∞* -Xmine < adjustment < -Xmaxe
    Hint: Use -verbose:sizes to see defaults for your platform, * denotes default -Xmx = max -Xms = initial free occupied
  • 15. Class Loader Subsystem
    • Loading, Linking and Initialization
    • Primordial Class Loader
    • Class Loader Objects
    • Namespaces
  • 16. Java 5 VM Enhancements
    • Class Data Sharing
    • Improvements in Garbage collection Algorithm
    • Server Class Machine Detection
    • Fatal Error Handling Mechanism
    • Access to Nano seconds timing
    • JVMTI Tool
    • Thread Priority Changes
  • 17. Java Platform v.6 - Garbage Collector (GC) updates
    • Significantly faster classLoader load/unload performance and improved footprint
    • Hierarchical Scanning—faster, memory hierarchy aware optimization for—Xgcpolicy:gencon. Paper in ISMM ’06 (Siegwart and Hirtzel)
      • Challenge: improving locality
          • Commercial workloads spend 45% stalled in memory requests.
          • Copying GC can improve object ordering, co-locating objects on the same page or cache line
      • While maintaining scalability…
          • Parallelism and workload balancing is essential for server workloads
  • 18. JSE 6: Compiler API
    • JSR 199 Compiler API:
      • Compiler c = new Compiler();
      • c.setOutputDir(“build/classes”);
      • c.setSourceDir(“src”);
      • c.compile();
      • c.run(“Main.class”)
  • 19. JSE 6: JDBC 4, JAXB 2.0, WS
    • Just tell driver to get a connection, less code.
    • java.sql.SQLXML support
    • Instead of dealing with XML at angle-bracket level:
    • @XmlType public class SomeBean {}
    • //this bean now matches an XML document
    • @WebService public class Hello {}
    • //deployable after writing client factory code
  • 20. Summary
    • Java virtual machine translates operating system- and hardware-independent bytecodes to specific machine code and executes them
    • Major improvements for concrete JVM implementations just-in-time compiler and adaptive optimization
  • 21. The Java Virtual Machine (JVM) Java code native code local heap Components of Java / The Execution Environment network untrusted classes trusted classes native methods operating system class loader instance class file verifier JIT primordial class loader native method loader native method area execution engine Security Manager class area JVM Java code native code
  • 22. Java Security
    • Major technical challenge for network-oriented SW technology
    • Key Architectural feature
    • Protects end-users from hostile programs downloaded across a network from un-trusted sources
  • 23. Java Modes of Use
    • Applets: Auto-run when view web page
    • Applications: Traditional program (performance?)
    • Beans: Component (like OLE object)
    • Servlets: Server-side applications
    • Aglets: Intelligent Agents
    • Doclets: Configurable doc generator
    • Embedded Systems
    • Smart Cards (“JavaCard”)
  • 24. Java 1.0 Security Policy
    • Sandbox Policy (for applets)
      • Cannot access local filesystem or devices
      • Network connections only to applet load source
      • Cannot invoke any local program or library
      • “ Untrusted” indicator on top-level windows
      • Cannot manipulate basic classes or another ThreadGroup
      • Appletviewer CL can be initialized to vary these
    • Applications unlimited in 1.0; can code a policy
  • 25. SecurityManager
    • Class defines check methods called by system
      • E.G. “checkRead(String filename)”
      • Method throws exception if invalid
    • To create a security policy from scratch:
      • Create a subclass (code) & instantiate
      • Install using System.setSecurityManager; this cannot be revoked or replaced
      • This is used to create the Sandbox
      • If no SecurityManager installed, all privileges granted
  • 26. Bytecode Verifier
    • Checks a classfile for validity:
      • Code only has valid instructions & register use
      • Code does not overflow/underflow stack
      • Does not convert data types illegally or forge pointers
      • Accesses objects as correct type
      • Method calls use correct number & types of arguments
      • References to other classes use legal names
    • Goal is to prevent access to underlying machine
      • via forged pointers, crashes, undefined states
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 27. ClassLoader
    • Responsible for loading classes
      • given classname, locates/generates its definition
      • always looks at “standard” classes first
      • every class has a reference to the classloader instance that defined it
      • keeps namespaces of different applets separate (different ClassLoader instances)
      • each ClassLoader instance ~ OS process
      • “ CLASSPATH” classes trusted in JDK 1.0-1.1, system classes trusted, otherwise invokes bytecode verifier
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 28. The sandbox
    • idea : limit the resources that can be accessed by applets
      • introduced in Java 1.0
      • local code had unrestricted access to resources
      • downloaded code (applet) was restricted to the sandbox
        • cannot access the local file system
        • cannot access system resources,
        • can establish a network connection only with its originating web server
    Java security models JVM sandbox resources remote code (applets) local code
  • 29. The concept of trusted code
    • idea : applets that originate from a trusted source could be trusted
      • introduced in Java 1.1
      • applets could be digitally signed
      • unsigned applets and applets signed by an untrusted principal were restricted to the sandbox
      • local applications and applets signed by a trusted principal had unrestricted access to resources
    Java security models JVM sandbox resources remote code (applets) local code signed and trusted unsigned, or signed and untrusted
  • 30. Fine grained access control
    • idea : every code (remote or local) has access to the system resources based on what is defined in a policy file
      • introduced in Java 2
      • a protection domain is an association of a code source and the permissions granted
      • the code source consists of a URL and an optional signature
      • permissions granted to a code source are specified in the policy file
      • grant CodeBase “http://java.sun.com”, SignedBy “Sun” {
      • permission java.io.FilePermission “${user.home}${/}*”, “read, write”;
      • permission java.net.SocketPermission “localhost:1024-”, “listen”;};
    Java security models JVM resources local or remote code (signed or unsigned) class loaders policy file
  • 31. Java Cryptography Architecture (Added in 1.1)
    • Java cryptography architecture (JCA)
      • Framework (API) for access to services implemented by pluggable “providers”
      • digital signature algorithms (DSA), message digest algorithms (MD5 & SHA-1), key-generation algorithms, simple certificate management (1.1 had no API for specific formats)
      • Simple key management tool (simple “database”)
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 32. Java 2: Each Class Has A Protection Domain 1 ... ... 1 1 Instance2 Class1 ClassLoader1 Policy Instance1 Class2 ProtectionDomain1 PermissionCollection CodeSource ProtectionDomain2 PermissionCollection CodeSource 1 Asks
  • 33. Security Classes
    • Protection Domain
    • Code Source
    • Policy
    • Permission and Sub Classes
  • 34. Java 2 Runtime Security Check Algorithm
    • If method M requires permission P
      • M’s implementation calls current SecurityManager’s checkPermission(P)
    • By default this calls new “AccessController” class
      • For each call stack entry, unwind from caller:
      • if caller’s ProtectionDomain lacks P, exception (fail)
      • if caller called “doPrivileged” without context, return
      • if caller called “doPrivileged” with context, check it: return if context permits P else exception (fail).
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 35. Java Cryptography Architecture (JCA) Changes in 1.2
    • Adds more APIs that providers can support
      • Keystore creation and management
      • Algorithm parameter management
      • Algorithm parameter generation
      • Conversions between different key representations
      • Certificate factory support to generate certificates and certificate revocation lists (CRLs) from their encodings (Sun implements X.509’s)
      • Random-number generation (RNG) algorithm
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 36. Java Cryptography Extension (JCE)
    • Adds encryption, key exchange, key generation, message authentication code (MAC)
      • Multiple “providers” supported
      • Keys & certificates in “keystore” database
    • Separate due to export control
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 37. Other Areas In Development: JSSE and JAAS
    • Java Secure Socket Extension
      • Implements SSL
    • Java Authentication and Authorization Service
      • Based on PAM: pluggable authenticators for passwords, smart cards, biometric devices, etc.
      • Authenticators may be required, requisite (stop on failure), sufficient (but not required), or optional
      • Adds user-centric (vs. code-centric) control: permissions granted to Principal (not just CodeSource), implemented through a modified SecurityManager
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 38. Java Advantages
    • Permits controlled execution of less trusted code (vs. ActiveX)
    • Permits fine-grained permission control
    • Attention paid to security
    • Portability
    • “ Instant installation”
    • Sun’s source reviewable ( not open source)
    August 3, 2010 (C) 1999-2000 David A. Wheeler
  • 39. Contact
    • [email_address] or call at 022-6148819
    • [email_address] or call at 022-61488916
    • For more information please visit: http://www.synergetics-india.com/
    • Find the latest IT News at http://www.synergetics-india.com/blog
    • Watch Technology Video’s at http://www.youtube.com/thesynergetics
    August 3, 2010 (C) 1999-2000 David A. Wheeler