Garbage Collection for Edge Computing Andrs Amaya Garca David May - - PowerPoint PPT Presentation

garbage collection for edge computing
SMART_READER_LITE
LIVE PREVIEW

Garbage Collection for Edge Computing Andrs Amaya Garca David May - - PowerPoint PPT Presentation

Garbage Collection for Edge Computing Andrs Amaya Garca David May Ed Nutting sourcecodeartisan.com bristol.ac.uk Introduction Modern programming languages provide a high-level view of data and control Python, C#, JavaScript,


slide-1
SLIDE 1

bristol.ac.uk sourcecodeartisan.com

Garbage Collection for Edge Computing

Andrés Amaya García David May Ed Nutting

slide-2
SLIDE 2

bristol.ac.uk sourcecodeartisan.com

Introduction

§ Modern programming languages provide a high-level view of data

and control

– Python, C#, JavaScript, etc... – Productivity – Trust § Modern languages are not used in embedded systems because

software garbage collectors:

– Impose high performance and memory overheads – Cannot be used in real-time systems

slide-3
SLIDE 3

bristol.ac.uk sourcecodeartisan.com

Objectives

§ Efficiently support modern languages in embedded systems – think

small IoT edge devices e.g. ARM Cortex-M processors.

§ Investigate hardware –instead of software– collectors – High run-time performance – Low memory requirements – Capable of hard real-time

slide-4
SLIDE 4

bristol.ac.uk sourcecodeartisan.com

Integrated Hardware Garbage Collection (IHGC)

§ Exact collector

– Every word has a 1-bit tag: pointer vs data

§ Indirection through handles

– Directory memory contains object’s metadata – Tightly integrated with processor

§ Hardware state machine for collector

– Each state transition performed in one memory cycle – Collector operates when the processor is not accessing memory

§ Allocations via an instruction

Register File Processor Pipeline Garbage Collector Directory Main Memory

Private bus Shared bus Shared memory bus bus

slide-5
SLIDE 5

bristol.ac.uk sourcecodeartisan.com

IHGC – Indirection Through Handles

Handle Pointer Offset Address Directory Size Mark Deep List

+

Allocated object Free Memory

slide-6
SLIDE 6

bristol.ac.uk sourcecodeartisan.com

IHGC – Indirection Through Handles

Handle Pointer Offset Address Directory Size Mark Deep List

+

Allocated object Free Memory

Pointers are not physical memory addresses

slide-7
SLIDE 7

bristol.ac.uk sourcecodeartisan.com

IHGC – Indirection Through Handles

Handle Pointer Offset Address Directory Size Mark Deep List

+

Allocated object Free Memory

Pointers are not physical memory addresses Directory has

  • bject metadata

and collection information

slide-8
SLIDE 8

bristol.ac.uk sourcecodeartisan.com

IHGC – Indirection Through Handles

Handle Pointer Offset Address Directory Size Mark Deep List

+

Allocated object Free Memory

Pointers are not physical memory addresses Directory has

  • bject metadata

and collection information Memory access in two steps: 1. Calculate main memory address 2. Access main memory

slide-9
SLIDE 9

bristol.ac.uk sourcecodeartisan.com

IHGC – Garbage Collection State Machine

§ Mark-Compact collector § Roots are pointers in the registers § Each state transition is performed in

  • ne memory cycle

Scan Root Check & Mark Root Pop Next Object Scan Object Word Check & Mark Pointer Load Object Info Read Word Clear Word Zero Word Write Word Mark Roots Mark Objects Compact

slide-10
SLIDE 10

bristol.ac.uk sourcecodeartisan.com

IHGC – Coordination

§ Mark stage – Pointers loaded from main memory are processed for marking – Conceptually similar to a traditional read barrier § Compact stage – Redirect memory access to the correct location when the object accessed is being compacted § Transparent from the program’s point of view § Does not incur pauses or performance penalties

slide-11
SLIDE 11

bristol.ac.uk sourcecodeartisan.com

Experimental Setup

§ Modelled an ARM Cortex-M0 alongside the IHGC § Benchmarks: – BEEBS – Python 3 scripts running on MicroPython § LLVM compiler

slide-12
SLIDE 12

bristol.ac.uk sourcecodeartisan.com

Results – BEEBS

slide-13
SLIDE 13

bristol.ac.uk sourcecodeartisan.com

Results – BEEBS

Comparable performance in programs that do NOT use dynamic memory

slide-14
SLIDE 14

bristol.ac.uk sourcecodeartisan.com

Results – BEEBS

Better performance in programs that use dynamic memory

slide-15
SLIDE 15

bristol.ac.uk sourcecodeartisan.com

Results – MicroPython

slide-16
SLIDE 16

bristol.ac.uk sourcecodeartisan.com

Results – Pauses

slide-17
SLIDE 17

bristol.ac.uk sourcecodeartisan.com

Results – Pauses

x1.5 larger heap

slide-18
SLIDE 18

bristol.ac.uk sourcecodeartisan.com

Results – Pauses

Up to 20% reduction in pauses when data width increases

slide-19
SLIDE 19

bristol.ac.uk sourcecodeartisan.com

Conclusion

§ IHGC splits collection work at the granularity of a memory cycle § Collection worked performed when the processor is not using the

memory

§ Comparable or better performance when running C programs § Python scripts run 1.5-7 faster in IHGC system § Hard real-time

slide-20
SLIDE 20

bristol.ac.uk sourcecodeartisan.com

Thank You! Questions?

Andrés Amaya García andres.amayagarcia@bristol.ac.uk sourcecodeartisan.com