JVM Memory Usage (1) by pgq13383


									      JVM Memory Usage (1)
• We have talked about memory usage
  informally for programs seen so far
  – Code area : instructions held in memory
  – Variable area : ‘permanent’ program variables
  – Stack area :
     • Parameter passing
     • Saving registers
     • Temporary variables

                      COMP10031 Lect 18               1

      JVM Memory Usage (2)
When dealing with Java we need to consider
  a bit more detail. We have
• Classes, which contain
  – Method Code
  – Class Variables
• Objects
  – Instance Variables (new variables for each
    ‘new’ object)

                      COMP10031 Lect 18               2

      JVM Memory Usage (3)
• Method calls
  – Parameters
  – Local variables
• Note:
  – Objects need to be allocated a unique piece
    of store for each ‘new’
  – Variables & Parameters can be either
    primitive types (e.g. int) or objects (e.g. String)

                      COMP10031 Lect 18               3

        JVM Memory Usage (4)
• A running Java program has three basic
  areas of storage (conceptually anyway,
  the reality is sometimes a bit different)
• A Class area
  – Just a static area of store which contains
      • Method Code
      • Class variables – either primitive values (e.g. int)
        or pointers (i.e. addresses) to Objects

                        COMP10031 Lect 18                         4

        JVM Memory Usage (5)
• A Stack area – similar to already
  discussed (note here we are talking about
  a real stack not the virtual machine stack)
  – To hold parameters passed to methods
  – Local variables
  – Temporary variables
  – Saved registers
  – Return links
• A Heap area
                        COMP10031 Lect 18                         5

            JVM Memory Layout

                        Local Variables

                                                  Object 1
  Class Variables                            Instance Variables
                                               Method Table
                                                  Object 2
                                             Instance Variables
                                               Method Table
  Method Code
                                                  Object 3
                                             Instance Variables
                                               Method Table
   Class Area                                      Heap
                        COMP10031 Lect 18                         6

              Memory for Objects(1)
  • When we write a java declaration like
      String s;

  • We know that it is initially ‘null’
  • It doesn’t become an object until we write
        s = new String(“abc”);

  • What is actually happening?
                       COMP10031 Lect 18            7

              Memory for Objects(2)
      String s;
  • Just reserves a (32 bit in ARM) location in
    memory somewhere e.g.
      s DEFW 0
  • Note that by convention, the value zero is
    used to represent ‘null’
  • What happens when we create a new
                       COMP10031 Lect 18            8

              Memory for Objects(3)
  s    1000
         0        • A new section of memory is
                    obtained (e.g. at addr. 1000)
                  • Right size for object
                  • Object is initialised
        b         • Address of object is written
                    to s
                  • How is memory obtained?
  String s;
  s = new String(“abc”);
                       COMP10031 Lect 18            9

              The Heap (1)
• Every time a new object (instance of a
  class) is created it must be allocated a
  new area of store, which is the right size to
  – A header (useful info e.g. object size)
  – Storage for instance variables
  – Storage for a table of methods (in practice,
    addresses of method code) which can be
    called on the object. (we will ignore the details
    of this)
                    COMP10031 Lect 18                          10

              The Heap (2)
• The JVM has a memory manager
• This contains a subroutine which is called
  whenever a ‘new’ is executed
• The JVM has an area of store, the heap,
  where the memory manager allocates
  memory for newly created objects. This is
  clearly dynamic, i.e. the heap grows as the
  program runs.

                    COMP10031 Lect 18                          11

            Heap Allocation
                                    Heap Ptr
                                                    Object 1
                                               Instance Variables
• A running program can                          Method Table
  continually create                                Object 2
                                               Instance Variables
  objects (x=new(MyO))                           Method Table

• Start from heap pointer                           Object 3
                                               Instance Variables
  (HP)                                           Method Table

• New object addr = HP
                                                Free Heap Area
• HP = HP + Obj size
• Heap will fill up
                    COMP10031 Lect 18                          12

   JVM Memory Layout (again)

                       Local Variables

                                                          Object 1
  Class Variables                                    Instance Variables
                                                       Method Table
                                                          Object 2
                                                     Instance Variables
                                                       Method Table
   Method Code
                                                          Object 3
                                                     Instance Variables
                                                       Method Table
   Class Area                                              Heap
                       COMP10031 Lect 18                                  13

                    Stale Objects
• Recall if we have e.g.

my_object = new(my_class(1));
my_object = new(my_class(2));

• The first created object is no longer
  referenced from my_object

                       COMP10031 Lect 18                                  14

           Stale object example
                                                            Object 1
• E.g. a ‘new’ creates                                 Instance Variables
                                     Old reference       Method Table
  Object 2                           now removed
                                                            Object 2
• Then a ‘new’                                         Instance Variables
  creates Object 3         my_object                     Method Table

  and is assigned to                                        Object 3
                                                       Instance Variables
  my_object                                              Method Table
• If no other
  references exist to
                                                        Free Heap Area
  Object 2 it is of no
  further use

                       COMP10031 Lect 18                                  15

         Garbage Collection
• As we are continually creating new
  objects, we can run out of store
• We would like to reclaim store if it is no
  longer useful
• An important part of the memory manager
  is a garbage collector
• Called when the heap is getting full
• Works out what is ‘garbage’
                   COMP10031 Lect 18              16

        Discovering Garbage
• All references in the class variable and
  stack areas are followed to objects
• Object is marked as ‘live’
• Any references in those objects are
  followed to other objects – also marked
• Etc. until no more unexplored references
                   COMP10031 Lect 18              17

        Reclaiming Garbage
• Every object on the heap is scanned
• Any object not marked is garbage
• Their store is ‘returned’ to the memory
• But we will inevitably get ‘holes’ – usually
  known as ‘fragmentation’
• Some older objects will still be ‘live’ while
  newer ones have become garbage
                   COMP10031 Lect 18              18

• If objects were all the same
  size we might be able to refill
  all the gaps (if we can work
  out where they are)
• But in practice they are all of
  varying sizes
• Makes reuse of freed memory
  quite complex

                  COMP10031 Lect 18         19

Compacting Garbage Collection
• Modern garbage collectors move all ‘live’
  objects together
• Free space is then all at the end of the
  heap again
• Similar to ‘defragmenting’ a windows disk
• Makes reallocation easier
• Scan phase is more complex – we move
  objects around and need to ‘fix’ references
                  COMP10031 Lect 18         20

  Impact of Garbage Collection (1)
• Without it your Java programs would soon
  run out of store.
• Creating a ‘new’ object has a significant
  overhead both in getting new store and
  eventually reclaiming the old
• When garbage collection occurs,
  programs may stop for noticeable periods

                  COMP10031 Lect 18         21

 Impact of Garbage Collection (2)
• No good for ‘real time’ systems, e.g.
  landing an aeroplane
• It is possible to devise ‘Incremental’
  garbage collectors which don’t stop for
  long periods
• It is possible to write Java programs that
  don’t keep growing heap memory – if you
  understand & think about it!

                  COMP10031 Lect 18            22


To top