Automatic Heap Sizing: Taking Real Memory into Account

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTSASSACHUSETTS, A, AMHERST • MHERST • Department of Computer Science Department of Computer Science

1

Automatic Heap Sizing:Taking Real Memory into Account

Ting Yang, Emery Berger, Matthew Hertz, Scott Kaplan¶, Eliot Moss

Department of Computer Science Department of Computer Science¶

University of Massachusetts Amherst College Amherst MA 01003 Amherst MA 01002

{tingy,emery,hertz,moss}@cs.umass.edu [email protected]

UUNIVERSITY OF NIVERSITY OF MMASSACHUSETTSASSACHUSETTS, A, AMHERST • MHERST • Department of Computer Science Department of Computer Science 2

Appel _213_javac60MB real memory

Too small:GC a lot

Too large:page a lot

Optimal

Problem & Motivation

Heap size vs Running time


Problem & Motivation Multiprogramming makes it harder:

Amount of available real memory changes Impossible to select heap size a priori Strategy: adjust adaptively during executio

n


Outline

Problem & MotivationProblem & Motivation Paging behavior of Garbage CollectionPaging behavior of Garbage Collection VMM: collecting the information we VMM: collecting the information we

needneed Collector: adjusting heap size Collector: adjusting heap size

adaptivelyadaptively Experimental resultsExperimental results Conclusion & Future workConclusion & Future work


GC Paging Behavior

For strategy to work, need to relate: GC algorithm, heap size, and footprint

Analysis methodology: Obtain reference trace: simulate Jikes RVM under DS

S Process with LRU stack # faults at all memory sizes

GCs and programs traced: Mark-Sweep (MS), Semi-Space (SS), and Appel GCs SPECjvm98, ipsixql, and pseudojbb benchmarks


Heap Size = 240Mb

Memory = 145Mb

# of Faults ≈ 1000

50 seconds

extreme paging

substantial paging:

“looping” behavior

fits into memory

Fault curve: Relationship of heap size, real memory & page faults

Heap size=

0.5 second


Relationship between heap size and footprint

99870

76314802 .

..

R

xy

Page fault threshold =Our definition of footprint:

The amount of memory needed so that the time spent on page faults is lower than a ce

rtain percentage of total execution time


HeapUtilCurrentFPyAvailMemor

HeapUtilFootprint

HeapSize

A Linear Model:Heap size vs. Footprint

Heap footprint model:

Heaputil : SS 0.5; MS: 1 base : Jikes RVM plus live data size

How the GC can use this model:

baseHeapSizeHeapUtilFootprint


Strategy Overview

VMM ( in OS)VMM ( in OS) Knows memory allocation / available memory Needs to track/calculate application footprint

Garbage Collector (in User Space)Garbage Collector (in User Space) Has ability to change heap size Needs info: available memory, footprint

Request:mem alloc

footprint

Send: mem alloc

footprint


Outline





d e f g h i j k l m n c k l m ncb c d e f g h i j k l m n c k l m n

aba abc defghijklmn abc defghijklm n abdefghijckl n m abc defghijk mn l abc defghijlmn k abdefghijklmn c

4

n

321 1

Approach to Measuring Footprint

Memory reference sequence

LRU Queue

Pages in Least Recently Used order

Hit Histogram

Fault Curve

0000000000 0000

m n

1 14

l m nk l m nc k l m na b c d e f g h i j k l m n c k l m n

5

1

1 14114

i

i ihitfault 1

12 pages5 pages

Associated with each LRU position


VMM design: SegQ [SKW’99,KMC’02]

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

LRU Queue

Hit Histogram

Hot set Cold set Evicted set

0 0 0 0 0 0 0 0 0 0 0

Hot / Cold Boundary

0 0 0 0 0 0 0 0 0 0 0

CLOCK algorithm Strict LRU

• Decay histogram periodically

• Adaptive control of hot set size

FootprintMajor fault (on disk)Minor fault (in memory)


VMM design: SegQ [SKW’99,KMC’02]

Hot set Cold set Evicted set

Hot / Cold Boundary

CLOCK algorithm Strict LRU

Footprint

What is the footprint w.r.t 5%?

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0


Outline





Collector Design:

Communicate with VMM after GC First GC:

Appel, SS: HeapUtil = 0.5 Following GCs:

Calculate HeapUtil from history

HeapUtilCurrentFPyAvailMemor

HeapSize


Outline


needneed Collector: adjusting heap size adaptivelyCollector: adjusting heap size adaptively Experimental resultsExperimental results Conclusion & Future workConclusion & Future work


Experiments

Experimental setting: Jikes RVM 2.0.3 Dynamic SimpleScalar: extended with new VMM model Major fault = 5 million instructions = 5 ms @ 1 Gips Minor fault = 2000 instructions = 2 µs Page fault cost threshold = 5% - 10% Histogram collecting cost threshold = 1%

Adapting to fixed memory pressure Adapting to dynamic memory pressure

Add/Remove 15MB real memory after 2 billion insts


Memory under-utilized

Optimal heap

Paging a lot

Larger heap Fewer GCs Less P

aging

60MB Real MemoryAppel _213_javac



Increase memory: 15MBat 2 billion instructions



Decrease memory: 15MBat 2 billion instructions


Conclusion: Automatic Heap Sizing

New collector usually picks heap size that: Maximizes memory utilization (reducing GCs) While avoiding paging Linear model works well in practice Improves performance by up to 8x under pressure Cost of collecting information is low: around 1%

New collector adapts quickly to steady and to changing real memory allocations Within 1 or 2 major GCs


Ongoing Work Implement in real kernel Extend to more collectors Adjust during allocation, not just after G

C

Detailed graphs & tech report: http://www-ali.cs.umass.edu/~tingy/CRAMM

Automatic Heap Sizing: Taking Real Memory into Account

Documents