Advanced Object Oriented Systems
Download
Report
Transcript Advanced Object Oriented Systems
Advanced Object Oriented
Systems
(CM0318)
Lecture 12
(Last modified 28th February 2002)
1
Making Objects Work!
• In this lecture we’ll consider
implementation techniques for OO
languages:
– The underlying OO model
– The role of virtual machines
– The role of garbage collection
2
The underlying OO model
• There is no reason why OO languages can’t
be compiled into machine code, but some
kind of method look-up is normally needed.
Two obvious possibilities:
– a literal implementation of the class-hierarchywith-method-dictionaries concept
– a giant CASE statement
3
Class hierarchy metaphor
• Search an object’s class hierarchy. Pseudocode, for message m sent to object o:
c = o.class;
sel = m.selector;
while (c != null) {
if (c.methdict.containsKey(sel)) {
meth = c.methdict.get(sel);
}
else {c = c.superclass}
}
if (c==null) {<error>} else {meth(o, m.args)}
4
CASE statement metaphor
• Simply carry around a variant record that holds the
type (‘o_type’) and a pointer to the object:
o_types = (t1, t2,
c1 = <def of class
c2 = <def of class
c3 = <def of class
object = record
o_type: o_types;
case o_type of
t1: ^c1;
t2: ^c2;
t3: ^c3
end {object}
t3);
1 structure>;
2 structure>;
3 structure>;
5
CASE statement (ctd.)
• In the main code, we would have things
like:
case o.o_type of
t1: meth_c1(o, ...);
t2: meth_c2(o, ...);
t3: meth_c3(o, ...);
end {case};
• This would be the basis of a Pascal-style
implementation of an OO design too.
6
Virtual machines
• Rather than compile programs for a specific
real machine, why not compile for a virtual
machine and then implement an interpreter
for this VM?
• Advantages: portability of compiled code;
ease of porting compilers too; ...
• Disadvantages: a naive implementation will
be very slow
7
The Java model
Java program
Java methods (Java API)
native methods (dynamic
libraries)
host operating system
8
•
Byte
codes
example
Java code:
class Act {
public static void doMathForever() {
int i = 0;
for (;;) {
i += 1; i *= 2;
}
}
}
• Byte code (NB it’s stack-based)
0
1
2
5
6
7
8
9
iconst_0
istore_0
iinc 0, 1
iload_0
iconst_2
imul
istore_0
goto 2
//
//
//
//
//
//
//
//
03
3b
84 00 01
1a
05
68
3b
a7 ff f9
9
Making it more efficient
• Clearly a virtual machine is inefficient. One
solution is Just In Time (JIT) techniques, in
which the byte-codes are translated into
native machine code the first time a method
is executed.
10
Garbage collection
• Garbage collection is essential:
– temporary objects can accumulate in large
quantities
– responsibility for destruction of objects won’t
always lie with the creator, so best to allow it to
occur automatically
11
Reference counting
• Objects are normally allocated on the heap.
• For each object, maintain a count of the number of
references to it in the system.
• When an object’s reference count drops to zero it
is unreachable and so can be deleted.
• Advantage: reference counting is local, so the
program doesn’t have to stop for long garbage
collection sessions
• Disadvantage: if there are circularities, e.g. two
objects referring to each other, then the reference
counts will remain non-zero even when the objects
12
become unreachable
Mark-and-sweep
• Start at one or more roots, from which any objects that are
accessible in the system can be traced. (E.g., in Smalltalk,
the System Dictionary is one of the roots.)
• In the first pass, mark all the objects that are accessible;
• In the second pass, free up all the space allocated to objects
not marked.
• Advantage: all garbage can be detected
• Disadvantage: in this simple model, it’s very time
consuming
• In some OO implementations, reference counting is relied
upon until space runs out, then a mark-and-sweep is done
13
The Mark algorithm
• set all objects to be unmarked
• for each root
– do procedure mark_recursive for this object
• procedure mark_recursive
– if the object isn’t marked then
• mark it, and
• for each object referred to by the current one
– do procedure mark_recursive
14
The sweep algorithm
• Simply Sweep right through object memory,
freeing memory for un-marked objects
15
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• Initial state. In this particular system, it will
always be the case that all objects can be
16
reached either from Root 1 or Root 2.
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• We’ll start with root 1. As it isn’t marked,
mark it
17
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• As it wasn’t previously marked, follow the
objects to which it refers recursively. Result
18
of following link to object 1 shown.
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• Result of following link to object 3 shown.
Note that 2 is already marked.
19
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• Now follow root 2. Again it isn’t marked so
mark it. Object 5 already marked, so don’t
20
follow that link.
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• Follow link to object 6
21
Illustration
root 1
root 2
1
2
3
4
5
6
7
8
9
10
11
12
• Don’t follow link to object 7 since already
marked. Follow link to object 10.
22
Illustration
root 1
root 2
1
2
3
5
6
7
9
10
8
12
• THE SWEEP STAGE: Simply free memory
pertaining to unmarked objects
23
Generational Collectors
• Idea - divide heap into two or more generations of objects.
When an object is created it’s put into the youngest
generation; if it survives a predetermined number of
garbage collection it’s promoted to an older generation; ...
• objects in the youngest generation are collected more
frequently than in the older generations; objects in the
oldest generation are collected very infrequently.
• Benefits: most objects are collected very soon after
creation, and so the young-generation space remains pretty
empty and not seriously fragmented; similarly, objects in
the oldest-generation space don’t need to be moved around
all that often to defragment the space because it’s only
24
slowly changing.
Some suggested reading
• Venners, B., Inside the Java Virtual Machine,
McGraw-Hill, 1998.
• The Java VM specification:
http://java.sun.com/docs/books/vmspec/index.html
25
So what have we learned?
• There are various OO paradigms
• An OO approach to implementation of data
structures tends to make much use of
defining methods in terms of other methods
• Modern OO applications may well need to
be persistent and/or distributed
• Implementation of OO languages requires
clever techniques for efficiency
26
Next ...
• Analysis and design are crucial!!
27