Low Level Programming

1
Low Level Programming

• Teaching team
• Martin Slade (module leader), room K356, e-mail
  M.Slade_at_staffs.ac.uk, xtn 3554
• Bill Fone, room K213, e-mail W.Fone_at_staffs.ac.uk
  , xtn 3304
• Ian Sunley, room K210, e-mail
  G.I.Sunley_at_staffs.ac.uk, xtn 3465

2

• Website
• www.soc.staffs.ac.uk/mss1/llp/llp-index
• powerpoint versions of lecture slides, the
  practical worksheets and example answers will be
  made available on the website
• Book
• Programming for the Java Virtual Machine, Joshua
  Engel, Addison-Wesley
• Classes
• 1 lecture and 1 practical class per week

3
Assessment

• Exam - 50
• Programming test - 50 - in week 12 or 1st week
  after end of semester
• specification for a program will be handed out
  some time prior to test
• as preparation for test you will have opportunity
  to write program that matches specification
• in test you will be given an incomplete version
  of the program with 1 or 2 methods missing
• you will have to implement the missing methods

4

• We shall look at
• how high level languages constructs and
  data/objects are represented at a low level
• how events, errors and exceptions are handled at
  a low level
• how program loading, linking and dynamic
  extension of programs work and how assemblers
  translate your low level code into executable
  programs

5
Virtual Machine

• A virtual machine is an abstraction of a CPU that
  is then implemented in software to run on any
  hardware
• JVM defined by Java Virtual Machine Specification

6
JVM specification

• Specification defines 3 things
• Set of instructions and semantics for those
  instructions i.e. what instructions do
• Binary format for executable java files - class
  file format - to hold bytecodes and other info
• Constraints applied to loading classes (including
  verifying that classes do not specify behaviour
  that compromises the integrity of operation of
  JVM) and linking classes together

7

• Instructions - called bytecodes - binary values
• Instructions based on stack based architecture,
  but with special object oriented extensions
• stack based temporary values used in
  calculations held in an operand stack rather than
  in registers
• to represent bytecode we will be using Oolong
• Oolong - is an assembly language that permits
  bytecodes to be represented using characters that
  are then translated into executable class files
  by an assembler for Oolong

8
Operand stack

• bipush 2 push the number 2
• bipush 3 push the number 3
• iadd add them together - result on stack

• most byte code instructions in java expect to
  find their operands on the operand stack, and
  leave the result on top of the stack

OPERAND STACK
9
JVM view of memory

• most CPUs see memory as a large array of bytes
• To implement a data object you simply allocate
  the required number of contiguous bytes - then
  access data components by using appropriate
  offset within area of memory so allocated
• To call a function - you jump to location of
  first instruction of function in memory

10
JVM view of memory

• JVM does not allow byte level access to memory
• Instead it has instructions for allocating
  objects to memory, retrieving and modifying data
  fields, invoking methods that belong to those
  objects, without requiring any knowledge of the
  byte level address for those components
• Components are identified within class files by
  symbolic references

11

• getstatic java/lang/System/out Ljava/io/PrintStrea
  m
• ldc "Hallo World"
• invokevirtual java/io/PrintStream/println
  (Ljava/lang/String)V
• 1st instruction gets value of the out field of
  object java/lang/System and places it on the
  operand stack. It is an object reference of type
  PrintStream.
• 2nd instruction pushes reference to literal
  string "Hallo World" onto operand stack.

12

• invokevirtual java/io/PrintStream/println
  (Ljava/lang/String)V
• 3rd instruction invokes the println method - the
  definition of the method i.e. its bytecode is
  found in the java/io/PrintStream class, it
  requires 2 components to be on the stack - an
  argument of type java.lang.String (what to print)
  and and a reference to a PrintStream object
  (where to print to)
• (Ljava/lang/String)V
• this is a type descriptor which says that println
  takes a string as a parameter and returns void -
  the V

13
organisation of JVM

• conceptually divided into 5 areas
• java stack(s) - 1 stack per user thread
• heap - where object data fields kept
• class area - byte code and constants held here -
  method area and constant pool
• native method stacks - to support execution of
  native methods
• Execution engine
• Today look at java stack(s) and the heap in more
  detail - the others look at in later lecture

14
(No Transcript)
15
java stack

• a data area called a stack frame is created for
  each method when it is invoked.
• the java stack consists of a stack of stack
  frames - the top frame is the stack frame of the
  method that is currently executing - called the
  active stack frame
• each stack frame contains an operand stack
  (guaranteed to be large enough to handle all
  operations in method), space for local variables,
  parameters and return value, and pointer to
  currently executing instruction in method area -
  called program counter

16

• Only the parameter values and local variables of
  the top stack frame (i.e. the current method) can
  be seen and used by java bytecode.
• when method is invoked a new stack frame is
  created on top of the java stack
• the current PC is saved in stack frame of calling
  method (so that after the called method returns,
  execution in the calling method can begin again
  from the point at which the called method was
  called)

17

• program counter of new method points to first
  bytecode of called method
• when method completes, its stack frame is deleted
  and stack frame immediately beneath it becomes
  active stack frame once more
• program counter of new active frame points to
  bytecode after method call

18
(No Transcript)
19
heap

• heap - storage area that is used to hold data
  that may continue to exist beyond the lifetime of
  the method that created it i.e. there are
  references to the data/objects that exist outside
  of a particular method
• object data items stored on heap
• each object is associated with class in class area

20
heap

• object on heap has space for each non-static data
  field of the object's class, and for each
  non-static field in it's superclass (and the
  super class of it's super class - up the
  inheritance hierarchy until it reaches the root
  class Object)
• static data is held in the class area of a class

21
Example - invocation of method
22

• diagram shows state of JVM just before
  invokevirtual on println during execution of
  hallo world program
• operand stack has references to out and "hallo
  world" on it, local var has reference to args
  array.
• out, "hallo world" string and args are all on the
  heap
• program counter has reference to invokevirtual
  instruction

23
(No Transcript)
24

• diagram shows state of JVM after invokevirtual
  has been executed
• new stack frame for println has been put on top
  of java stack, the references to string and out
  have been deleted from operand stack of main by
  invokevirtual instruction, the local vars in new
  stack frame now contain references to out and
  "hallo world" on heap (local vars because they
  are parameters), program counter points to first
  instruction in println, old PC still points to
  invokevirtual in main - incremented when
  invokevirtual returns

25
(No Transcript)
26

• diagram shows state of JVM after println has
  completed
• stack frame for println is deleted off the stack
  , old stack frame is now active stack frame, PC
  now points to return instruction after
  invokevirtual, operand stack is now empty (no
  return values from println) and local var still
  points to args, heap still has out and "hallo
  world" objects on it but they are not referenced
  by anything

27
garbage collection

• JVM can reclaim objects that occupy space on the
  heap once there are no longer any active
  references to the object - called garbage
  collection
• object can be garbage collected when it is no
  longer 'alive'
• object is alive when
• reference to the object is found in static field
  of a class, in operand stack or in local vars of
  any stack frame of a method on java stack
• reference to the object is found in data field in
  the heap of a 'live' object

28

• thus at least one object in a set of objects that
  refer to each other on the heap must be referred
  to by a reference from elsewhere e.g. java stack
  method stack frame
• in certain circumstances JVM itself keeps a
  reference to an object on heap