Memory Management for Mobile Operating Systems Niel Lebeck, Arvind - - PowerPoint PPT Presentation

▶
memory management for mobile
SMART_READER_LITE
LIVE PREVIEW

Memory Management for Mobile Operating Systems Niel Lebeck, Arvind - - PowerPoint PPT Presentation

Jul 09, 2023 209 likes •561 views

End the Senseless Killing: Improving Memory Management for Mobile Operating Systems Niel Lebeck, Arvind Krishnamurthy, Henry M. Levy, Irene Zhang 1 Disclaimers I currently work at Google (not on Android) This work is not connected with

slide-1
SLIDE 1

End the Senseless Killing: Improving Memory Management for Mobile Operating Systems

Niel Lebeck, Arvind Krishnamurthy, Henry M. Levy, Irene Zhang

1

slide-2
SLIDE 2

Disclaimers

  • I currently work at Google (not on Android)
  • This work is not connected with Google
  • Research was done while I was a graduate student at UW
  • All data is from our experiments or open-source resources
  • All opinions are our own

2

slide-3
SLIDE 3

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Implementation and evaluation

3

slide-4
SLIDE 4

Today’s mobile memory management is bad for users and applications

  • Each app gets a fixed maximum memory budget
  • Mobile OS kills apps when the device runs out of memory
  • Even if apps are not actively using their memory
  • Restarting apps takes time
  • Developers must optimize app memory usage

App

Working set

4

slide-5
SLIDE 5

Traditional swapping is not a solution

  • Not suited to managed languages (e.g., Java)
  • Garbage collection causes swapping, confuses working set estimation (WSE)
  • Page-granularity swapping and WSE do not fit variable-sized objects
  • Not suited to latency-sensitive touch devices
  • On-demand swapping causes stuttering and delays

5

slide-6
SLIDE 6

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Implementation and evaluation

6

slide-7
SLIDE 7

Key insight

  • We can co-design the runtime and OS to improve mobile memory

management

  • Possible because modern mobile platforms require all apps to use the

same runtime

7

slide-8
SLIDE 8

Marvin

  • Android memory manager co-designed with Android’s Java runtime
  • Reintroduces swapping to the mobile environment

8

slide-9
SLIDE 9

Marvin

  • Marvin has three main features:
  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collector [Hertz 05]

9

slide-10
SLIDE 10

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Stubs
  • Reclamation table
  • Object access interposition
  • Marvin’s features
  • Implementation and evaluation

10

indirection layer between objects allows the runtime and OS to coordinate lets the runtime transparently take action

slide-11
SLIDE 11

Stubs

  • We need an indirection layer between objects referencing each other
  • Catch accesses to swapped-out objects
  • Stubs provide that indirection layer
  • Small pseudo-objects that sit in the Java heap and point to the “real” object
  • Store copies of the real object’s references

11

  • bj A
  • bj B
  • bj C

stub Java Heap Reclaimable Object Space

slide-12
SLIDE 12

Reclamation table

  • We need a way for the runtime and OS to coordinate
  • Tell OS which objects can be reclaimed
  • Prevent OS from reclaiming an object being used by the runtime
  • A shared-memory reclamation table allows that coordination
  • Stores an object’s location and size, and has metadata bits for locking

12

  • bj A
  • bj B
  • bj C

stub Java Heap Reclaimable Object Space Reclamation Table

address size res app lock kernel lock 0xc00d00a0 512 1 0xc00e1410 128 1 2 0xc0002320 8192 1

slide-13
SLIDE 13

Object access interposition

  • The runtime needs a way to transparently act when app code

accesses objects

  • Restoring swapped-out objects
  • Update working set metadata
  • Object access interposition is a set of paired interpreter and compiler

modifications implementing those actions

  • Interpreter directly acts when performing object accesses
  • Compiler generates additional ARM64 instructions around object accesses

13

slide-14
SLIDE 14

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collector
  • Implementation and evaluation

14

slide-15
SLIDE 15

Ahead-of-time swap

  • Runtime uses object access

interposition to set dirty bit in

  • bject header
  • Runtime clears dirty bit after saving

an object

  • Kernel checks dirty bit before

reclaiming an object

15

foo

Reclaimable Object Space Swap File

foo

foo.setX(42); 1

Compiled ARM64 code Interpreter

slide-16
SLIDE 16

Ahead-of-time swap

  • Runtime uses object access

interposition to set dirty bit in

  • bject header
  • Runtime clears dirty bit after saving

an object

  • Kernel checks dirty bit before

reclaiming an object

16

foo

Reclaimable Object Space Swap File

foo

1

slide-17
SLIDE 17

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collector
  • Implementation and evaluation

17

slide-18
SLIDE 18

Object-level working set estimation

  • Runtime uses object access interposition to set access bits
  • Runtime scans access bits and updates longer-term WSE metadata

18

foo

int x = foo.getX(); Compiled ARM64 code

Garbage collector heap-walk

0 | 0 | 1100 | 0000 Read bit Write bit Read shift register Write shift register 1 | 0 | 1100 | 0000 0 | 0 | 1001 | 0000 Interpreter

slide-19
SLIDE 19

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collector
  • Implementation and evaluation

19

slide-20
SLIDE 20

Bookmarking garbage collector

  • Runtime uses object access interposition to maintain stub references
  • GC detects stubs and reads references without touching underlying
  • bjects

20

foo.setMember(bar)

foo stub(foo) Java Heap Reclaimable Object Space Reclamation Table bar

member = null member = null member = 0x7000001a member = 0x7000001a

Compiled ARM64 code Interpreter

slide-21
SLIDE 21

Bookmarking garbage collector

  • Runtime uses object access interposition to maintain stub references
  • GC detects stubs and reads references without touching underlying
  • bjects

21

foo stub(foo) Java Heap Reclaimable Object Space Reclamation Table bar

member = null member = null member = 0x7000001a member = 0x7000001a

Garbage collector

slide-22
SLIDE 22

This talk

  • Motivation
  • Key insight and Marvin
  • Marvin’s mechanisms
  • Marvin’s features
  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collector
  • Implementation and evaluation

22

slide-23
SLIDE 23

Marvin implementation

  • We modified the Android Runtime (ART) to implement Marvin
  • Default policy keeps the foreground app’s objects in-memory
  • For experiments, we trigger reclamation in the runtime

23

slide-24
SLIDE 24

Evaluation

  • Experimental setup:
  • Pixel XL phones
  • Android 7.1.1 (or our modified build)
  • Questions:
  • Does Marvin let users run more apps?
  • Does ahead-of-time swap work?
  • What is Marvin’s overhead?

24

slide-25
SLIDE 25

Does Marvin let users run more apps?

  • We periodically started instances of a benchmark app
  • Initializes a 220MB heap with a mix of 4KB and 1MB arrays
  • Deletes and re-allocates 20MB of those arrays every 5 seconds
  • We measured the number of active apps: apps that are alive and

making progress on their workloads

25

slide-26
SLIDE 26

Does Marvin let users run more apps?

  • Marvin can run over 2x as many apps as stock Android
  • On Android w/ Linux swap, a little allocation makes apps unusable

26

Android w/ Linux swap consistently crashed early

slide-27
SLIDE 27

Does ahead-of-time swap work?

  • Marvin reclaims memory much faster than Android w/ Linux swap

Marvin Android

≈8 seconds ≈100ms

27

slide-28
SLIDE 28

What is Marvin’s overhead?

  • When objects are memory-

resident, execution overheard depends on proportion of

  • bject accesses
  • Overhead is reasonable (15%)
  • n PCMark benchmark

28

slide-29
SLIDE 29

Related work

29

Acclaim [Liang 20] SmartSwap [Zhu 17] A2S [Kim 17] MARS [Guo 15] Policies distinguish between foreground and background apps Similarities with Marvin

slide-30
SLIDE 30

Related work

30

Acclaim [Liang 20] SmartSwap [Zhu 17] A2S [Kim 17] MARS [Guo 15] Similarities with Marvin

Addresses incompatibility of garbage collection and kernel-level swap

slide-31
SLIDE 31

Related work

31

Acclaim [Liang 20] SmartSwap [Zhu 17] A2S [Kim 17] MARS [Guo 15] Perform swapping at the kernel level rather than the runtime level Differences from Marvin

slide-32
SLIDE 32

Conclusion

  • Problem: Today’s mobile memory management is inadequate
  • Insight: We can co-design the runtime and OS to improve memory

management

  • Solution: Marvin improves mobile memory management with three

co-design features

  • Ahead-of-time swap
  • Object-level working set estimation
  • Bookmarking garbage collection

32

slide-33
SLIDE 33

Thanks!

  • Marvin source code is available on GitHub:

https://github.com/UWSysLab

  • Contact: nl35@cs.washington.edu

33