Real Time Java Real Time Java Filip Pizlo , Jan Vitek Filip Pizlo , - - PowerPoint PPT Presentation

▶
real time java real time java
SMART_READER_LITE
LIVE PREVIEW

Real Time Java Real Time Java Filip Pizlo , Jan Vitek Filip Pizlo , - - PowerPoint PPT Presentation

Mar 20, 2023 206 likes •612 views

An Emprical Evaluation An Emprical Evaluation of of Memory Management Memory Management Alternatives Alternatives for for Real Time Java Real Time Java Filip Pizlo , Jan Vitek Filip Pizlo , Jan Vitek Purdue University Purdue University

slide-1
SLIDE 1

An Emprical Evaluation

  • f

Memory Management Alternatives

for

Real Time Java

An Emprical Evaluation

  • f

Memory Management Alternatives

for

Real Time Java

RTSS RTSS Dec 2006 Dec 2006

Filip Pizlo, Jan Vitek Purdue University West Lafayette, IN, USA Filip Pizlo, Jan Vitek Purdue University West Lafayette, IN, USA

slide-2
SLIDE 2

2

Motivation

  • Real Time Java programmers are forced

to choose between two memory management styles:

  • Scoped Memory
  • Real Time Garbage Collection
  • To date, no direct performance

comparison exists.

slide-3
SLIDE 3

3

Contribution

  • We present the first open-source

implementation of both scoped memory and RTGC in one VM

  • A discussion of software engineering

benefits and dangers of scoped memory versus RTGC*

  • An empirical performance evaluation

using two realistic Real Time Java applications

slide-4
SLIDE 4

4

Talk Overview

  • Summary of Scoped Memory
  • Summary of RTGC (Metronome Style)
  • Software Engineering Issues
  • Evaluation
slide-5
SLIDE 5

5

Scoped Memory

Scope A Scope B Scope C Heap Immortal

slide-6
SLIDE 6

6

Scoped Memory

Scope A Scope B Scope C Heap Immortal Parent Relation

slide-7
SLIDE 7

7

Scoped Memory

Scope A Scope B Scope C Heap Immortal

Thread A Thread B Threads create the scope hierarchy as they enter scopes.

slide-8
SLIDE 8

8

Scoped Memory

Scope A Scope B Scope C Heap Immortal Invalid Refs

slide-9
SLIDE 9

9

Scoped Memory

Scope A Scope B Scope C Heap Immortal

slide-10
SLIDE 10

10

Scoped Memory

Scope A Scope B Scope C Heap Immortal

Thread A Thread B Objects in scopes are freed when the scope is exited.

slide-11
SLIDE 11

11

Scope A Scope B Scope C Heap Immortal

Scoped Memory

Thread A Thread B Objects in scopes are freed when the scope is exited.

slide-12
SLIDE 12

12

Scope A Scope B Scope C Heap Immortal

Scoped Memory

slide-13
SLIDE 13

13

Scoped Memory

  • What we wanted: avoidance of GC interruptions.
  • What scoped memory gives us:
  • Mostly-safe, somewhat-manual memory

management

  • To avoid GC interruptions we add no-heap

threads:

  • A no-heap thread cannot have references to the

heap.

slide-14
SLIDE 14

14

myScope = new LTMemory(65536, 65536); myAction = new Runnable() { public void run() { new Object(); // allocated in scope // deallocated after we exit the scope } }; // run myAction in myScope myScope.enter( myAction );

Scoped Memory Example

slide-15
SLIDE 15

15

Scoped Memory Summary

  • Threads enter/exit scopes following a stack

discipline

  • Objects deleted when scope exited
  • Dynamic checks:
  • Write Checks: prevent dangling pointers
  • Read Checks: prevent no-heap threads from

accessing the heap.

slide-16
SLIDE 16

16

RTGC (The Metronome Way)

T1 T2 T3

slide-17
SLIDE 17

17

1) Control collector interruptions: (collector interruptions ~ 1ms) 2) Insure that collector methods used by mutator are highly predictable (worst case ~ best case)

RTGC (The Metronome Way)

T1 T2 T3 GC

slide-18
SLIDE 18

18

RTGC Implementation

  • “Insure that collector methods used by

mutator are highly predictable (worst case ~ best case)”

  • We go to some trouble to make sure that

the following are predictable:

  • Write Barrier
  • Allocation
slide-19
SLIDE 19

19

Write Barrier

T1 GC Write Barrier GC Idle GC Active

  • What it is:
  • What we need it to do:

A small piece of code inserted by the compiler at every write of a reference to memory. It guarantees that the collector does not lose track of objects. Do not exhibit worse performace during collection than when the collector is idle!

slide-20
SLIDE 20

20

Write Barrier

  • Idea: Whatever the worst case is, we

need to simulate it.

  • Solution: Our write barrier always

performs at worst case when the GC is idle.

slide-21
SLIDE 21

21

Allocation

  • No slow path! Collector ensures that all

free space is accounted for.

  • Worst case: empty freelist, allocate new

page, bump pointer in page

slide-22
SLIDE 22

22

Software Engineering Issues

  • Scoped Memory
  • Real-Time Garbage Collection

We now consider the software engineering impact of the two styles of Real Time Java memory management.

slide-23
SLIDE 23

23

Scoped Memory

Pros Cons

Fail-Fast Fast Alloc Fast Free Read Checks Write Checks Not Automatic

slide-24
SLIDE 24

24

RTGC

Pros Cons

Safe Automatic Overhead Analysis Burden

slide-25
SLIDE 25

25

Performance

  • Methodology
  • RTGC Overhead
  • RTZen Performance
  • CD Performance
slide-26
SLIDE 26

26

Methodology

  • We use the OpenVM virtual machine

and the J2c ahead-of-time compiler.

  • Our platform is an Pentium IV with

512MB RAM running Linux 2.6.

  • Memory Management:
  • Java-GC (mostly-copying, semi-space)
  • Java-GC + Scopes
  • RTGC
slide-27
SLIDE 27

27

Performance

  • Methodology
  • RTGC Overhead
  • RTZen Performance
  • CD Performance
slide-28
SLIDE 28

28

RTGC Overhead

  • We use the industry standard SPECjvm98

benchmark suite.

  • Three collectors:
  • Java-GC
  • RTGC w/o write barriers
  • RTGC
slide-29
SLIDE 29

29

compress jess db javac mpegaudio mtrt jack

  • Geo. Mean

20 40 60 80 100 120 140 c e x E . e m i T s a t n e c r e P f

  • a

v a J

  • C

G Java-GC RTGC HNoBarL RTGC

SPEC Performance

7% overhead 32% overhead

slide-30
SLIDE 30

30

Performance

  • Methodology
  • RTGC Overhead
  • RTZen Performance
  • CD Performance
slide-31
SLIDE 31

31

RTZen Performance

  • RTZen is a real-time CORBA implementation.
  • RTZen uses scoped memory. We run it with and

without scopes.

  • We test four memory management configurations:
  • Java-GC
  • RTGC
  • Scopes
  • Scopes w/o checks (see paper)
slide-32
SLIDE 32

32

RTZen Latency v. Time, Java-GC

100 200 300 400 500 600 Time HsecsL 10 20 30 40 50 60 70 y c n e t a L H s i l l i m L

58ms 44ms 1.56ms (best)

slide-33
SLIDE 33

33

RTZen Latency v. Time, RTGC

100 200 300 400 500 600 Time HsecsL 0.5 1 1.5 2 2.5 3 3.5 y c n e t a L H s i l l i m L

1.4ms 2.9ms 1ms

slide-34
SLIDE 34

34

RTZen Latency v. Time, Scopes

100 200 300 400 500 600 Time HsecsL 0.5 1 1.5 2 2.5 3 3.5 y c n e t a L H s i l l i m L

2.1ms 1.7ms 0.8ms (RTGC is 38% worse)

slide-35
SLIDE 35

35

Performance

  • Methodology
  • RTGC Overhead
  • RTZen Performance
  • CD Performance
slide-36
SLIDE 36

36

CD Latency v. Iteration, Java-GC

50 100 150 200 250 300 Iteration Number 20 40 60 80 100 120 y c n e t a L H s i l l i m L

114ms 4ms

slide-37
SLIDE 37

37

CD Latency v. Iteration, RTGC

50 100 150 200 250 300 Iteration Number 5 10 15 20 25 y c n e t a L H s i l l i m L

18ms 6ms

slide-38
SLIDE 38

38

CD Latency v. Iteration, Scopes

50 100 150 200 250 300 Iteration Number 5 10 15 20 25 y c n e t a L H s i l l i m L

10ms 8ms (RTGC is 80% worse) 4ms

slide-39
SLIDE 39

39

Conclusion

  • In RTGC, raw throughput suffers only 7% for

SPECjvm98 (though it is 32% worse in the jess benchmark).

  • RTGC has between 38% (RTZen) and 80% (CD)

worse latency in the worst case.

  • Your Mileage May Vary, but:
  • If you can tolerate the overhead, RTGC is easier.
  • Scopes are still best if your specification is tight.
  • Read the paper for a more in-depth evaluation!