topics covered in lecture:

1
Lecture 10

• topics covered in lecture
• loading of classes
• linking of classes
• associated reading - Engel, chapter 6 8.

2
creation of a class

• 1. loading - getting binary file from source
• 2. linking - mapping class file info into runtime
  data structure representation of class
• a). verification of class checking correctness
  of imported class
• b). preparation - allocates memory for class
  variables and sets default values
• c). resolution - of symbolic references to direct
  references (can be postponed until reference used
  rather than in linking)
• 3. initialisation invoking java code that
  initialises class vars to proper starting values

3
1. loading

• loading implemented by a ClassLoader class
  (except arrays)
• obtain a stream of binary data that represents
  the class (normally class file format) - obtained
  from local file system, from across network, from
  archived file, etc
• parse the stream and construct in the method area
  of JVM of an implementation specific internal
  representation of the class.
• create instance of class java.lang.Class to
  represent type

4

• class loader can load before first active use and
  cache binary data, but can only report error in
  load on first active use of class
• Arrays cannot be extended and thus structure of
  class known to JVM - thus JVM constructs array
  class representation without use of a loader
• 2 types of class loader - user-defined class
  loader boot-strap class loader - part of JVM
• user-defined - can extend class loading
  facilities e.g. loading from different sources
  such as encrypted file, database, or generated
  dynamically as output from executing process

5

• At runtime a class is known to JVM by its
  pathname and the identity of its class loader.
  When class references another class, that class
  will be loaded by same class loader. Classes can
  only access classes loaded by same class loader -
  providing possibility of multiple name spaces.
• Class loader parses representation of class. It
  uses pass 1 of verifier to determine whether
  representation is in correct class file format,
  but also determines whether representation is for
  a class of the specified name (NoClassDefFoundErro
  r is thrown)

6
2. linking

• effectively - linking loaded class in with other
  classes already loaded ready for execution -
  consists of
• verification of class to ensure that it is
  structurally valid (pass 2 and 3 of verifier)
• preparation of class
• resolution

7
2. a) verification

• need to verify byte codes - because compiler may
  be buggy or someone may have hand crafted or
  modified class file to do something illegal e.g.
  manipulate bytes in other methods in class file
  and crash the virtual machine - jump beyond end
  of method crashing jvm or produce non existent
  byte codes, etc.
• essentially 4 passes - pass 1 - verification of
  gross features of class file format (during
  loading), pass 2 - verification of more detailed
  features of class file, pass 3 - verification of
  byte code, pass 4 - verification of references
  (during use of reference)

8
verification - pass 1

• checks for magic class file code identifier
  CAFEBABE
• checks length of file consistent - each class
  file component says how long it is - so checks
  lengths are consistent - can tell if class file
  truncated or extended
• checks for obviously spurious data in entries

9
verification - pass 2

• Checks whether final classes not subclassed,
  final methods not overridden
• checks for existence of superclasses, (except for
  Object)
• checks for consistency in constant_pool entries -
  are they correct format and hold valid data e.g.
  If entry should hold an index to another entry in
  constant_pool, does it hold a value that could be
  an index to an entry of the correct type
• checks whether class/method/field names and
  descriptors are well formed

10
verification - pass 3

• pass 3 - checks byte code - could verify
  bytecodes during execution but that is too
  costly. It is simplest to verify all at once
  during linking phase.
• Checks that all branches/jumps, etc lie within
  code array for method and are aligned with the
  start of a byte code instruction
• checks all accesses to local var slots occurs
  within array of local vars
• checks all indices into constant_pool access
  entry of the correct type

11
path analysis

• then performs analysis of the execution paths of
  the byte code of each method. It maintains a log
  of the state of the stack and local var slots
  after the execution of each byte code in each
  possible execution sequence.
• State of stack is number and types of entries on
  stack
• State of local var slots is types of values held
  in each location
• Verifier does not execute the bytecode
  instruction but monitors the effect on the stack
  and local var state that the execution of a byte
  code instruction would have.

12

• During path analysis the verifier
• checks for valid byte codes
• checks that type and number of operands on stack
  or in local var slots are appropriate for given
  byte code operation
• checks parameters to method call are consistent
  with method signature (correct number, type and
  order)
• checks field variables are only accessed using
  operations of appropriate type
• checks that local var slots not accessed before a
  proper value is assigned to them
• checks to ensure that whichever path of execution
  is taken to get to specific byte code all paths
  leave operand stack with same number and types of
  values on them

13
verification - pass 4

• some checks are delayed until the first time the
  code for a method is invoked - to avoid loading
  of classes into JVM when they may not be
  required.
• verification of symbolic references (full
  pathname of class/method/field)
• checks whether field/method/class exists
• checks for consistency between field/method/class
  descriptor and and actual type of
  field/method/class
• checks access rights e.g. is it private or
  public, etc.

14
2. b) Preparation

• creates static fields for the class and
  initialises them with default values

15
2. c) Resolution (can be postponed)

• class files contain symbolic references to
  classes, objects, fields and methods of other
  classes and to fields and methods in own class in
  constant_pool
• resolution is the process of locating entity
  identified by symbolic reference and replacing
  symbolic reference with direct reference - a
  pointer or offset to class , field or method
  within heap or method area for class
• constant pool entry resolved only once ready for
  first use - later uses are to direct reference

16

• 2 strategies for timing of resolution -
• early resolution - link and resolve all symbolic
  references from initial class and then
  recursively all symbolic references of referenced
  classes until all references resolved
• program would be completely linked before main()
  executed

17

• or late resolution - resolution occurs on demand
  or first use of symbolic reference
• could select strategy in between - early
  resolution of symbolic references internal to
  class and to already loaded and linked classes
  but late resolution of references to classes that
  are not yet loaded and linked
• but jvm must behave as if it uses late resolution
  - it will only throw errors it encounters during
  linking when a program first attempts to use a
  symbolic reference and not before (and never
  throw the error if the symbolic reference is not
  used)

18
resolution of class references

• check if class type has already been loaded into
  current name space - if not then pass fully
  qualified name i.e. the symbolic reference itself
  to class loader
• class loader loads the class file, parses info
  into internal data structures and creates a Class
  object to represent the class
• process then repeated for each superclass until
  reach Object class

19
resolution of field/method references

• both field and method references have entry for
  class in which they are declared
• resolution involves first resolving the class to
  which the field/method belongs
• then if class resolution successful jvm searches
  symbolic references in internal representation of
  constant_pool of class and checks for existence
  of field/method and checks access permissions,
  throwing exceptions if there is a problem
• if all ok then jvm replaces symbolic reference
  with direct reference to appropriate internal
  data structures

20
direct references

• references into entities in method area are
  likely to be native pointers or offsets into
  method table for instance methods
• whereas references to entities on the heap are
  likely to be offsets within the structure used
  for the heap
• all depends on exact structure of internal data
  structures

21
3. Initialisation

• set class variables to proper initial values - as
  defined by user initialisation code
• with constants - static finals - values placed in
  constant_pool or in-lined into bytecode stream
  and not placed in a class field
• after class loaded, linked and initialised you
  can access static fields and methods and create
  instances of it

22

• if class has a super class then before class is
  initialised, its super class must be initialised.
• In order to initialise the super class (if not
  already in the JVM) must in turn be loaded,
  verified, prepared (possibly resolved) before
  being intialised. This process is recursive until
  we get to Object which has no super class.

23
Instantiation

• most classes are instantiated explicitly via new
• some classes are instantiated implicitly - String
  arguments to main, Class object that represents
  internal details of a class, creation of String
  objects via concatenation operator

24

• JVM allocates space on heap for instance
  variables of class (and superclasses including
  hidden variables) and other run-time data
  elements and initialises instance vars with
  default values
• then JVM initialises instance vars with proper
  specified initial values - from source code
  declaration and/or object constructor method
  (creates instance initialisation method ltinitgt())