Memory Management

Case study (JVM & CLR)

 KIRAN KUMAR V


LENIN THUMMALAPALLI
C++ Memory Architecture
Specification
HEAP

STACK

STATIC Area

CODE
JVM Architecture
Specification
 Method Area

Type Field
constant pool
information information

Method Table

Reference to
Method Class class loader
information and class
variables Class
 Method Area
 Fully qualified type’s
name.
Type Field  Fully qualified direct
Constant
Information Informa super
pool
tion
class name.
 Whether class or an
Method Ref. to interface
Class class loader Method
Informa- Table  type's modifiers
variables and class
tion
Class  list of the fully
qualified
names of any direct
super
interfaces
 Method Area
Type Field  Ordered set of
Informa Constant Pool Informa constants
tion tion - string
- integer
- floating point
- final variables
Method Ref. to
Class class loader Method  symbolic references to
Informa- Table
variables and class - types
tion
Class
- fields
- Methods
 Method Area
 field’s name
Type  field’s type
Constant Field
Informa  field’s modifiers
pool Information
tion (subset )
- public
- private
Ref. to - protected
Method Method - static
Class class loader
Informa- Table - final
variables and class
tion - volatile
Class
- transient
 Method Area
 Method’s name
Type  Method’s return type
Constant Field  Number and type of
Informa Informa
pool parameters
tion tion  Modifiers (subset)
Method
- public
Table
- private
Method Class - protected
Ref. to
Information variables - static
class loader
- final
and class
- synchronized
Class
- native
- abstract
 Method Area
Type Field
Constant
Informa Informa
pool
tion tion  ordered set of class
Method variables
Table
- static variables
Method
Class Ref. to
Informa
variables class loader
tion
and class
Class
 Method Area
Type  Reference to class
Constant Field
Informa Informa loader is used for
pool dynamic linking.
tion tion
 instance
Method
Table java.lang.Class is
created every type for
Method Ref. to the following info.
Class
Informa Class loader - getName();
variables
tion And class - getSuperClass();
Class - isInterface();

- getInterfaces();
- getClassLoader();
 Method Area
Type Field  Used for quick ref. to
Constant
Informa Informa
pool
tion tion method.

 Contains name and

Method index
Method
Class Ref. to Table in symbol ref. array
Informa
variables class loader
tion
and class
Class
 Heap Memory
 Objects and arrays are allocated in
this area.
 Two different threads of the same
application, however, could trample
on each other's heap data.
One possible Design of Object
Allocation on Heap
Another Design of Object
Allocation
Another Design of Object
Allocation
 Lock on Objects
 object is associated with a lock (or mutex) to
coordinate multi-threaded access to the
object.
 Only one thread at a time can "own" an
object's lock.
 Once a thread owns a lock, it can request
the same lock again multiple times, but then
has to release the lock the same number of
times before it is made available to other
threads.
 Array Allocation on Heap
 The name of an array's class has one
open square bracket for each dimension
plus a letter or string representing the
array's type.
 The class name for an array of ints is
"[I“.
 The class name for three-dimensional
array of bytes is "[[[B".
 The class name for a two-dimensional
array of Objects is "[[Ljava.lang.Object".
Design of allocation of array on
Heap
 Java Stack
 Java stack stores a thread's state in
discrete frames.
 Each frame contains
- local variables Area.
- operand stack
- frame data
 Local variable Area
 organized as a zero-based array of
cells.
 Variables are accessed through their
indices.
 Values of type int, float, reference, and
return Address occupy one cell.
 Values of type byte, short, and char
also occupy one cell.
 Values of type long and double occupy
two consecutive cells in the array.
ass Example3a {
public static int runClassMethod(int i, long l, float f, double d, Object o, byte b) {
return 0; }
ublic int runInstanceMethod(char c, double d, short s, boolean b) {
return 0; }
 Operand Stack
 operand stack is also organized as an array
of cells.
 local variables are accessed via array
indices, the operand stack is accessed by
pushing and popping values.
 instructions take their operands from
- operand stack
- immediately following the opcode
- constant pool
 iload_0 // push the int in local variable 0
 iload_1 // push the int in local variable 1
 iadd // pop two ints, add them, push result
 istore_2 // pop int, store into local variable 2
 Frame data
 Frame data is needed to support
- constant pool resolution
- normal method return
- exception dispatch
- debugging.
class Example3c {
public static void
addAndPrint() {
double result =
addTwoTypes(1, 88.88);

System.out.println(result);
}
public static double
addTwoTypes(int i, double
d) {
return i + d;
}
}
class abc {
public int a;
String str;
Example
abc() {
a=10; atr=“string1”;
}
public void print{ System.out.print(a+” “+str); }
}
interface def {
void add();
}
class pqr extends abc implements def {
static int b;
final int c=50;
String s;
pqr(int m) { super(); b=m; s= new String(”string2”); }
void add() { a=a+c; add1(); }
static void add1() { c=b+50; }
}
class Main {
public static void main(String[] s) {
pqr p=new pqr(20);
p.add();
p.print();
}
}
class abc { Type Constant pool
public int a;
String str;
info
abc Symbol ref.
array
a st <init print
abc() { java.lang.Objec
t r >
a=10; 10
str=“string1”; Isclass=true “string1”
} modifier=4
Field
public void print{
System.out.print(a+”
info
name Type Modifier inde
“+str); a int 5 x 0
} str String 4 1
} Method
info
name ret.typ npa modifierparlist codept Method Class variable
<init> e void r 0 1 r Table
name index
print void 0 5 <init> 2 null
print 3
 Class Area of abc in Method
area Symbolic ref. array
abc
java.lang.Objec
t
name Type Modifier index
Isclass=true
a int 5 0
modifier=4
ptr. to interface list str int 4 1
ptr. to symbolic ref. array
ptr to field info
name ret.typ npa modifierparlistcodeptr
ptr to method info
<init> e void r 0 5
ptr to class variable list print void 0 5

ref. to class loader

ref. to Class Method name index in sym

ref.
<init> 2
ptr to method table
print 3
interface Type Constant pool
def { info
def
Symbol ref.
void add(); java.lang.Objec array
add
t
}
Isclass=false
modifier=4 Class
Field info
Method variables
null infonpa modifierparlist codept
name ret.typ
add e void r 0 4 r null

Method
Table
name
index
add 0
 Class Area of def in Method
area
def
java.lang.Objec
t
Isclass=false
Symbolic ref. array
modifier=4
ptr. to interface list
ptr. to symbolic ref. array
ptr to field info
name ret.typ npa modifierparlistcodeptr
ptr to method info
add e void r 0 4
ptr to class variable list

ref. to class loader

ref. to Class Method name index in sym

ref.add 0
ptr to method table
class pqr extends abc implements
def {
Type Class variables
static int b; info
pqr
final int c=50;
String s; abc b
pqr(int m) { super(); b=m; Isclass=tr
s= new ue
String(”string2”); }
void add() { a=a+c; add1(); } modifier= Field info
4
}
Constant
static void pool
add1() { c=b+50; }
name Type Modifier inde
b int 4,6 x 0
Symbolic ref. array
b c s <init super add add c int 4,7 1

50 > 1 S String 4 2

Method Method
info npa
name ret.typ modifierparlistcodept Table
name
<init> e void r 1 4 r
index
<init> 3
add void 0 4 add 5
add1 void 0 4 add 6
super void 0 4 1
super 4
 Class Area of pqr in Method
area Symbolic ref. array
pqr
abc
Isclass=true name Type Modifier index

modifier=4 b int 4,6 0

ptr. to interface list ( to c int 4,7 1

def)
ptr. to symbolic ref. array S String 4 2

ptr to field info

name ret.typ npa modifierparlistcodeptr
ptr to method info
<init> e void r 1 4
ptr to class variable list (b) add void 0 4
add1 void 0 4
ref. to class loader
super void 0 4
ref. to Class
Method name index in sym
ptr to method table
ref.
<init> 3
add 4
class Main {
public static void main(String[] s) {Type
Constant pool
pqr p=new pqr(20); info
Main
p.add(); Symbol ref.
p.print(); java.lang.Objec array
} t mai 20
} n
Isclass=true
Class
Field info modifier=4
Method variables
null infonpa modifierparlist codept
name ret.typ
main e void r 0 4 r null

Method
Table
name
index
main 0
 Class Area of Main in Method
area
Main
java.lang.Objec
t
Isclass=true
Symbolic ref. array
modifier=4
ptr. to interface list
ptr. to symbolic ref. array
ptr to field info
name ret.typ npa modifierparlistcodeptr
ptr to method info
main e void r 0 5,6
ptr to class variable list

ref. to class loader

ref. to Class Method name index in sym

ref.main 0
ptr to method table
 Main Main pqr abc
Main Main pqr

p str
stack main p main s

Heap a,b,c
string2

Main pqr
Main pqr Main pqr
p

p p
main
Pqr.<init
>
Pqr.<init
> abc.<init
>
Main pqr abc Main pqr abc
Main pqr abc

p str p str str

p
s s s
add
add
a,b,c
add1 string2
a,b,c string2
a,b,c string2

Main pqr abc Main pqr abc

p str p str
s s str
s

prin
a,b,c
t
string2
a,b,c string2
 Relation between C++
memory structure and JVM
memory structure
 Constant STATIC Area
pool
CODE

Field Class
Informa variables
tion

Type
Informa
Metho
Metho
tion Metadata dd
Area
Area
Method Ref. to
Method
Informa class loader
Table
tion and class
Class
Garbage collection

JVM Heap

C++ Heap
 Frame data

Operand
Stack Threaded
Threaded
JVM
JVM
Stack
Stack

JVM stack
Threads

C++ stack
Responsibilities of Memory
Mgr
 Chop the chunk.
 Allocate Requested number of bytes.
 Provide necessary information to
garbage
collector.
 Collect the bytes returned by garbage
collector.
 Defragment the chunks.
 Design Choices
 How to allocate bytes
- Contiguous memory allocation.
- Non contiguous memory allocation.
 How many bytes to be allocated
- exact requested number of bytes.
- Allocate bytes in terms of 2^n (Buddy
System).
 How defragmentation to be done
- Compaction.
- Buddy system.
 JVM Memory Manager

Algorithms Followed
 Noncontiguous Memory Allocation.
 First fit to choose approperiate chunk.
 Buddy system to chop a chunk.
 Buddy system for defragmentation.
 How to implement memory
manager
 Need of 4 threads
- Memory allocator.
- Memory Defragmenter.
- Chunk cleaner.
- Data manager.
When VM requests m bytes
 Allocator
1. Checks for first chunk with size
>=m+4.
2. If available chops it and returns to VM
else requests OS for new chunk.
 Data Manager inserts an entry in Memory
Allocation Table (for garbage collector ).

Starting Size requested Size Allocated

address
 Garbage Collection
 For each entry in MA Table GC moves to
starting address+ size requested address,
checks the ref. count. If zero returns the
index of table entry to Data Manager.
 Data Manager deletes the entry from MAT
and adds in Defragment Table.
 For each entry in Defragment Table,
Defragmenter combines the consecutive
fragments.
Starting Address Size
 Design problem
VM requests an array of bytes
- to store data in Method Area.
- for stack frame.
- for object on Heap.
MM doesn’t know the purpose of bytes.
How does MM allocates memory in three
different address spaces for different type of
requests.
Use Three MMs. Each MM has its own
addr. Space. Its responsibility of VM to
direct the requests to appropriate MM.
 Optimal size of chunk
 For Method Area MM 10K
 For Stack 16K
 For Heap 1K, 10K,
32K
Initial State of Chunk pool
 Trade off between performance and
efficient memory usage.
 first and top pointers of each pool is
set to null
 Chunk Pool cleaner
 similar to Garbage collector.
 For every 5s cleaner returns all
chunks more than 5.
ClR Memory Management
 CLR Names to Memory
Areas
Method Area as Type Area
Stack as Roots
Heap as Heap, but two
heaps
- Managed heap
- Unmanaged
In JVM entire heap is managed.
heap
 Necessity of Unmanaged
Heap
M/C 1

Java JVM
M/C 2

M/C 1
C#
CLR
VB M/C 2

Some Languages allow pointers. So to

support pointers Unmanaged heap is
supported
 What is the difference
JVM MM
- Allocation is complex.
- Defragmentation is simple.

ClR MM
- Allocation is simple.
- Defragmentation is complex.
 JVM Memory Manager

Algorithms Followed
 Contiguous Memory Allocation.
 Compaction for defragmentation.
 Lazy Defragmenter
 Memory Managers
 Type Memory manager.  GC runs.
 Roots Memory  No GC.
manager.  GC runs.
 Managed heap  No GC.
manager.
 Unmanaged
To deallocate heap
Unmanaged Memory
Finalizers should be used.
manager.
 Before GC After GC
Memory
Allocation

Next Ptr
Obj 3
Obj 2
Obj 1
Thank You