Interval-Based Memory Reclamation Haosen Wen , Joseph Izraelevitz, - - PowerPoint PPT Presentation

Interval-Based Memory Reclamation

Haosen Wen, Joseph Izraelevitz, Wentao Cai,

• H. Alan Beadle and Michael L. Scott

University of Rochester PPoPP’18

• 2/19-

Background

• Unlike lock-based concurrent data

structures, non-blocking ones allow updates to happen concurrently with other accesses.

• Specifcally, a thread might try to

reclaim a block while others still have access to it.

A B

Thread 1 Thread 2

• (Thread-safe) garbage collecting languages tend to

bring high overhead.

• 3/19-

The Problem

• Manual approaches are majorly based on

"reservations," a global metadata, which require expensive store-load fences to update:

• Hazard Pointers (HP) [Michael, PODC’02] reserves a

minimum number of blocks per thread, but updates reservation every time a thread follows a shared pointer.

• Epoch Based Reclamation (EBR) [Fraser, thesis’04];

[Hart et al., 2007] only issues memory fences at

beginnings and ends of operations, but a stalling thread may cause an unbounded amount of blocks to be unreclaimable.

• Our approach improves EBR by making it

robust to thread stalling.

• 4/19-

B A C A B

Reserved by Thread 1

B C

Reserved by Thread 2

Store-load Fence by T1 B A C C B

Reserved by Thread 1

B C

Reserved by Thread 2 Reclaimable

• Thread 1 is

traversing a linked list and Thread 2 is retiring block A.

• Blocks in global

array of HPs are reserved from reclamations.

• Store-load fences

are issued on every HP update.

• Number of HPs per

thread is usually small, but can be unbounded in some cases.

Not reclaimable

Hazard Pointers (HP)

• 5/19-

B A C 1

Reserved by Thread 1

2

• The Epoch counter is

a slow-ticking "clock"

• Each thread puts the

current epoch E in reservation at the beginning of

• perations, reserving

all objects retired on and after epoch E.

• As a result, only

blocks retired before the lowest reservation can be reclaimed.

Not reclaimable

Epoch-Based Reclamation (EBR)

Epochs Block A 1 2 3 4

Epoch: 2

Block B

Lowest reservation: 1

Reserved by Thread 2 Thread 1 Thread 2

• 6/19-

A 1

Reserved by Thread 1

• The Epoch counter is

a slow-ticking "clock"

• Each thread puts the

current epoch E in reservation at the beginning of

• perations, reserving

all objects retired on and after epoch E.

• As a result, only

blocks retired before the lowest reservation can be reclaimed.

• Unbounded numbers
• f blocks may be tied

up if some thread is stalled: EBR is not robust to thread stalling.

Not reclaimable Epochs Block A 1 2 3 4

Epoch: 5

Block B Lowest reservation: 1

Zzzzzz... B C ...

Block C

Epoch-Based Reclamation (EBR)

Block D

D

• 7/19-

Thoughts about EBR

• EBR is not robust [Dice et al., 2016]: a stalled thread

can end up reserving an unbounded number of blocks, including blocks created after it stalled.

• If reservation of one thread can only hold a

bounded range of epochs, then a stalled thread can only reserve a fnite number of blocks.

• T
• ensure correctness, a block should be reserved

if its "life interval" ("lifetime" between its birth epoch and retire epoch) intersects with any reservation(s).

• 8/19-

Introducing Interval-Based Reclamation (IBR)

• 9/19-

A 2

Reserved by Thread 1

• IBR tracks the life

interval (hence the name) of all blocks.

• A block is reclaimable

if its life interval does not intersect with reservations of any thread.

• The reservation of

each thread contains a fnite range of epochs; a stalled thread won’t reserve any block born after the upper bound of its reservation.

• A thread updates its

upper reservation as it progresses.

Not reclaimable

Interval-Based Reclamation (IBR)

Epochs Block A 1 2 3 4

Epoch: 5

Block B Reserved epochs: [1, 2]

Zzzzzz... B C ...

Block C

1

• reclaimable

• 10/19-

T agged Pointer IBR (T agIBR)

• Update reservations when following shared
• pointers. Goal: reserve the target block

before pointer dereference.

• A tag in the pointer is guaranteed to be greater

than or equal to the birth epoch of its target.

1 1

Epochs Block A 1 2 3 4

Thread 1 Read(A) 2 1

Epochs Block A 1 2 3 4

Birth: 1 (Data) T ag:2 Birth: 2 (Data) T ag Block A

• 11/19-

2 Global Epoch IBR (2GEIBR)

• Always update upper reservations to the current

global epoch – faster (or simpler*).

• There is a potential trade-of between space

bound and throughput (or simplicity*) (in long- running operations).

1 1

Epochs Block A 1 2 3 4

Thread 1 Read(A) 4 1

Epochs Block A 1 2 3 4

Epoch: 4 Birth: 1 (Data) Birth: 2 (Data) Block A *with diferent T agIBR variants.

• 12/19-

Persistent Object IBR (POIBR)

• The most straightfarward implementation of IBR:

every thread can only reserve one epoch.

• Suitable only for data structures who persists
• histories. For example, one whose internal

pointers are immutable.

• 13/19-

Performance Results

• 14/19-

Experimental Setup

• Platform: Intel(R) Xeon(R) CPU E5-2699 v3.
• Processor: 2 sockets, 18 cores,

2 hyperthreads on each core: 72 hyperthreads in total. (Threads >72, some get stalled)

• Thread pinning strategy:

1 thread per core on one socket -> hyperthreads on the same socket -> next socket.

• 15/19-

Schemes in the test

• HP: Hazard Pointers
• EBR: Epoch-based reclamation
• T

agIBR

• (sub-variants: T

agIBR-FAA, T agIBR-WCAS in paper.)

• 2GEIBR: 2 Global Epoch IBR
• No MM
• (POIBR in paper)

• 16/19-
• ●
• 2000

4000 6000 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100

Threads

• Avg. of Unreclaimed Retired Blocks
• EBR

TagIBR 2GEIBR HP

Average retired-but-not-reclaimed objects per operation

Natarajan & Mittal’s Tree

• Michael’s Hash Map has similar performance

Number of hardware contexts Threads exceeding 72 get stalled

• 17/19-
• 10

20 30 40 50 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100

Threads Throughput (M ops/sec)

• No MM

EBR TagIBR 2GEIBR HP

Throughput (M ops/s)

Natarajan & Mittal’s Tree

• Michael’s Hash Map has similar performance

Number of hardware contexts

• 18/19-

Throughput (M ops/s)

Michael’s Linked List

• 0.000

0.025 0.050 0.075 0.100 1 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95100

Threads Throughput (M ops/sec)

• No MM

EBR TagIBR 2GEIBR HP

• 19/19-

Summary

• We presented Interval-Based Memory

Reclamation, a family of memory management schemes for non-blocking concurrent data structures.

• These showed throughput comparable to the

fastest existing approach(es), and are robust to thread stalling.

• In theory, T

agIBR is more suitable for data structures with long operations working on

• ld data; 2GEIBR for (almost) the rest.
• The artifact is available at:

https://zenodo.org/record/1168572