designing a trace format for heap allocation events trishul chilimbi, microsoft research richard...

Designing a Trace Format forHeap Allocation Events

Trishul Chilimbi, Microsoft ResearchRichard Jones, University of Kent

Ben Zorn, Microsoft Research

T. Chilimbi, B. Zorn (MSR), R.E. Jones (UKC) 2

Is Heap Allocation a Solved Problem?

Yes? Numerous techniques, 40+ years of research Fragmentation not an issue? (Johnstone et al.

ISMM98)

How much faster can it get?

No! Arenas, regions, user-defined heaps, etc. Scalability of MP allocators Data locality


Are our Evaluation Methods Sound?

Heap allocation important in: Streaming media applications

Long-running, quasi-real-time Server applications (Larson & Krishnan ISMM98)

Heavy load, complex structure, multi-threaded

“Large” applications (OS, word proc., etc.)

Current benchmarks (BZ’s especially): Small, single-threaded, short-running


Are Traces a Solution?

Yes? Easy to share, portable Captures real behaviors, real programs under real

loads Easy to use for experimental evaluations

No? Fixed format implies potential missing info

E.g., capturing references problematic Trace size a significant issue MP interleaving is non-deterministic


Contributions

HATF – an allocation trace format Trace contents focus on important issues Representation is flexible, portable Traces are compact, processing efficient

MetaTF – a language for describing trace formats

Raise awareness of issues What should be in a trace? Do you care about how a trace is

represented?


Assumptions and HATF Design Goals

We assume Long traces (100M events) are necessary Consumer will read/process events sequentially Ease of consumption critical

Minimal dependencies, resource requirements HATF design goals

Expressiveness – contents must be useful Compactness – 10% space reduction “valuable” Flexibility – allow limited extension (see MetaTF)


Trace Content

Standard allocation events Allocate, reallocate, free

Context In a specific region In a specific thread At a specific time

Attributes allow additional infoAllocate 16 11 39 4601 0xf4567 main

Tag Size Heap Thread Time Address Attrib.(e.g., caller)


Trace Representation

Fixed formats have obvious weaknesses Multiple address sizes (32 vs. 64-bit) Fields often empty (e.g., thread, heap)

Fields have exploitable properties Skewed or predictable distributions of values

Size often small, time monotonically increasing

HATF includes dynamic metadata Dynamically vary field width, interpretation


Changing Field Size with Metadata

size addresstag

32 0x4a0alloc

1024 0xa10alloc

1024 0xc10alloc

16 0xf10alloc

Fixed binary format

32 0x4a0alloc

1024 0xa10alloc

1024 0xc10alloc

HATF formatsetWidth size 1

setWidth size 2

setWidth size 1

16 0xf10alloc


Changing Field Interpretation

size addresstag

32 100alloc

32 200alloc

32 300alloc

1024 5000alloc

Fixed binary format

alloc

HATF format

setInterp addr stride 0 100

setInterp size none, addr none, …

32 400alloc

setInterp size default 32

alloc

alloc

alloc

1024 5000alloc


Representation Effectiveness

Is HATF necessary, useful? Comparison

Alternate representations HATF (size/time opt), fixed width binary,

ASCII With/without gzip compression Applications

Single-threaded, single-heap benchmarks Multi-threaded, multi-heap MS apps

Trace size, reading/writing costs


Trace Compression (Benchmark Avg.)

0

1

2

3

4

5

6

FixedBinary

ASCI I HATF HATF splitstream

Byte

s/D

ata

Reco

rd

w/ o gzipw/ gzip

16 12.3


Trace Compression (MS Apps, w. gzip)

0

1

2

3

4

5

6

7

8

9

FixedBinary

ASCII HATF ASCIItime=0

HATFtime=0

Byte

s/D

ata

Reco

rd

MS app1MS app2Bench avg.


Read Processing Time (Benchmark Avg.)

0

2

4

6

8

10

12

14

16

18

FixedBinary

ASCI I ASCI I Perl HATF

Mic

rose

cs./

Data

Reco

rd

w/ o gzipw gzip


HATF: Evaluation Summary

Space Without compression, HATF smallest With compression, ASCII and HATF close Representing 64-bit timestamps is

expensive

Time Current implementation limited by I/O Compression overhead small by comparison ASCII marginally slower to decode


Contributions

HATF – an allocation trace format Trace contents focus on important issues Representation is flexible, portable Traces are compact, processing efficient

MetaTF – a language for describing trace formats MetaTF ≈ HATF as XML ≈ HTML HATF reader/writer generated automatically

Raise awareness of issues


MetaTF – Beyond HATF

Aim: to facilitate exchange of trace data sets

Generalise HATF An expressive way of specifying traces

Allow easy construction of readers and writers Generate readers and writers automatically from the

specification

Separate representation from content


Component approach

Idea: Provide traces and API as a unit Separate representation from content

A trace contains event types Each event has a concrete representation Reveal content; hide representation

Implementation: jar files? Good for reader

Simple interface, e.g. Event getNextEvent(); Doesn’t help writer

Design trace format Implement interfaces


MetaTF approach

A trace comprises Document type definition (DTD) Trace event data

Meta-approach: say how to specify events, DTD

Abstract syntax notations SGML

Ride the XML wave Verbose, ASCII only

ASN.1 Obese, inflexible


MetaTF DTD example

Section heap 1 { alloc : (tag, size, address) { tag.value = 4; size.width = 4; size.interpretation = none; address.size = 4; address.interpretation = none; }}

Metadata can change representation of event, e.g.

Metadata alloc 2 Delta 310004

Tag Event Field InterpretationValue

Metadata alloc 2 Width 2


MetaTF effectiveness

Auto-generation of readers and writers from MetaTF DTD

Simple interface Class for each event type, inherited from Event Event getNextEvent(); void Event.putEvent();

Separation of content and representation to some degree


Architecture

Client

HATF10 (generated)

ClassesHigh-level readers/writers

BinaryReader/writer

GzippedReader/writer

ASCIIReader/writer

Data

Understandinterpretatio

nsRead/write

n bytes

Client-supplied


MetaTF: Evaluation summary

Simple but expressive syntax, familiar to programmers

Generated readers and writers, comparable performance

Separation of representation and content? Field properties User-supplied, low-level readers/writers

Interface Event classes getNextEvent, putEvent methods What else?


Preliminary Results: XML Compression

0

2

4

6

8

10

12

14

Byte

s / D

ata

R

eco

rd

XML ASCII HATF

w/ o gzipw/ gzipw/ xmill

25.5


Summary

Heap allocation research faces challenges We want to support easy, effective research HATF, MetaTF are suggestions

Content issues What is the minimum content? How to we define extensible formats?

Representation issues Is HATF sufficiently better than ASCII? How to separate, hide representation?

Organisation issues What other meta-information should be stored?

What do you think?


Status

HATF Preliminary implementation complete Trying to make code/traces available Hoping 3rd party will develop

implementation from specification Will help fix specification, implementation

MetaTF Preliminary implementation in progress Definition converging


Feedback – You tell us…

What else does HATF need to contain? How important are references?

Does anybody really care about representation? Should we just pick one and everybody will

be happy?


Backup Slides


Talk Overview

Motivation HATF – Heap Allocation Trace Format

Design goals Trace content Trace representation Representation Effectiveness

MetaTF – specifying trace formats Design Generating readers and writers Traces as “Components”


Separating Content and Representation

Ideally, representation and content would be entirely separate

User could use trace via standard API with no external dependencies

Trace + API would be delivered as a “unit” Similar in spirit to components (Java Beans,

COM) No “standard” off-the-shelf way to achieve

this Best thing we can think of is to make

readers/writers easy to acquire and use


ASCII versus Binary Representation

ASCII Portable, easy to examine and debug Manipulated via text scripting tools (Perl) Potential to ride the XML wave

Binary More compact representation (more later) Faster to read Contents exported to ASCII on demand

We chose… Binary


HATF Metadata

Metadata commands embedded in data Field sizes range from 0 to 8 bytes Field interpretations (mini compression

ops) Compute field value as some function

Examples: None, default, base/offset, delta, stride

Size/interpretation stay in effect until changed again

Reader interprets value of fields on-the-fly


Metadata Example

Goal: encode most allocate sizes in 1 byte Example trace contents:

Metadata: setWidth field:size width:1 Data: allocate size=40, addr=0x3ff, … Metadata: setWidth field:size width:2 Data: allocate size=1024, addr=0xa10, … Data: allocate size=1024, addr=0xc10, … Metadata: setWidth field:size width:1 Data: allocate size=16, addr=0xf00, … Data: allocate size=24, addr=0xf10, …


Trace Compression (MS Apps, w/o gzip)

0

5

10

15

20

25

30

35

FixedBinary

ASCI I HATF ASCI Itime=0

HATFtime=0

Byte

s/D

ata

Reco

rd

MS app1MS app2


HATF Compression across Apps

02468

101214161820

Byte

s/D

ata

Reco

rd

w/ o gzipw/ gzip

XML

<!element size (#PCDATA)><!element address (#PCDATA)><!element time (#PCDATA)><!element thread (#PCDATA)><!element heap (#PCDATA)><!element attributes (#PCDATA)><!element alloc size address time thread heap attributes><!element reallocNoALloc address address time thread heap attributes><!element reallocAllocFree address address time thread heap attributes><!element reallocAlloc address address time thread heap attributes><!element reallocFree address address time thread heap attributes><!element free address time thread heap attributes><!element createHeap thread heap attributes><!element destroyHeap thread heap attributes><!element createThread thread attributes><!element destroyThread thread attributes><!element comment attributes>


HATF1.0 specified in MetaTF1.1

tag.width = 1; size.width = 4; size.interpretation = none;address.width = 4; address.interpretation = none;attributes.width = 0; attributes.interpretation = none;time.interpretation = default 0;thread.interpretation = default 0;heap.interpretation = default 0;

section heap 1 { reallocNoAlloc : (tag, address, address, time, thread, heap, vfield) { tag.value = 3; } reallocAllocFree : (tag, address, address, time, thread, heap, vfield) { tag.value = 4; } reallocAlloc : (tag, address, address, time, thread, heap, vfield) { tag.value = 5; } reallocFree : (tag, address, address, time, thread, heap, vfield) { tag.value = 6; }

alloc : (tag, size, address, time, thread, heap, vfield) { tag.value = 1; } free : (tag, address, time, thread, heap, vfield) { tag.value = 2; }createHeap : (tag, thread, heap, vfield) { tag.value = 7; } destroyHeap : (tag, thread, heap, vfield) { tag.value = 8; } createThread : (tag, thread, vfield) { tag.value = 9; } destroyThread : (tag, thread, vfield) { tag.value = 10; }}

designing a trace format for heap allocation events trishul chilimbi, microsoft research richard...

Documents

jones ukc

zorn msr

160xf10alloc slide

interpretation slide

metatf slide

setinterp size

trace formats

caller slide