KESO An Open-Source Multi-JVM for Deeply Embedded Systems Isabella - - PowerPoint PPT Presentation

▶
keso
SMART_READER_LITE
LIVE PREVIEW

KESO An Open-Source Multi-JVM for Deeply Embedded Systems Isabella - - PowerPoint PPT Presentation

Jan 10, 2024 432 likes •873 views

KESO An Open-Source Multi-JVM for Deeply Embedded Systems Isabella Thomm, Michael Stilkerich , Christian Wawersich, Wolfgang Schrder-Preikschat Department of Computer Science 4 Distributed Systems and Operating Systems Friedrich-Alexander

slide-1
SLIDE 1

Department of Computer Science 4 Distributed Systems and Operating Systems Friedrich-Alexander University Erlangen-Nuremberg

Isabella Thomm, Michael Stilkerich, Christian Wawersich, Wolfgang Schröder-Preikschat

http://www4.cs.fau.de/Research/KESO http://www4.cs.fau.de/~mike stilkerich@cs.fau.de

KESO

An Open-Source Multi-JVM for Deeply Embedded Systems

slide-2
SLIDE 2

stilkerich@cs.fau.de - JTRES ‘10

Statically-Configured Embedded Systems

2

 comprehensive a priori knowledge

  • code
  • system objects (tasks/threads, locks, events)
  • system object relationships (e.g., which tasks access which locks)

 example: electronic control units (ECU) in cars

  • mass product ➟ immense cost pressure
  • programming languages: C, C++, Assembler
  • operating system: OSEK/VDX, AUTOSAR
  • static configuration
  • scalability classes
  • tailored to the application
  • ECU consolidation
  • application isolation
slide-3
SLIDE 3

stilkerich@cs.fau.de - JTRES ‘10

Java and Static Embedded Systems

3

 benefits

  • more robust software (cf., MISRA-C)
  • software-based spatial isolation
  • infrastructure for new technologies (e.g., state migration)

 problems

  • low-level programming inconvenient/expensive
  • dynamic code loading
  • fully-featured Java runtimes (e.g., J2ME configurations)
  • overhead
  • code is interpreted or JIT compiled (execution time)
  • dynamic linking (footprint)
  • reflection (footprint, analyzability)
slide-4
SLIDE 4

stilkerich@cs.fau.de - JTRES ‘10

Outline

 Motivation: Statically-Configured Embedded Systems  KESO: Overview  Inter-Domain Communication with Portals  Evaluation

4

slide-5
SLIDE 5

stilkerich@cs.fau.de - JTRES ‘10

KESO: Overview

5

 JVM tailoring (instead of fixed configurations)

  • static applications, no dynamic class loading
  • no Java reflection
  • ahead-of-time compilation to Ansi C, VM bundled with application

 scheduling/synchronization provided by underlying OS

  • currently AUTOSAR/OSEK OS
  • accustomed programming model remains

 current limitations

  • simple error hook instead of Java exception handling
  • garbage collector does not bound external fragmentation
  • no support for Java monitor concept
slide-6
SLIDE 6

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C

Domains: realms of {memory,service}protection

  • containers for control flows and system objects
  • appear as a separate JVMs to the application

System Objects Task C

slide-7
SLIDE 7

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

Domain Zero (TCB)

GC

Domain Zero

  • trusted control flows of KESO’s runtime environment
  • currently only the garbage collector
slide-8
SLIDE 8

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B

OSEK / AUTOSAR OS

Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

OSEK / AUTOSAR OS

  • provides threading/scheduling facilities
  • temporal isolation, hardware-based spatial isolation

Domain Zero (TCB)

GC

slide-9
SLIDE 9

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B

Microcontroller OSEK / AUTOSAR OS

Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

Domain Zero (TCB)

GC

Typical Targets

  • low-end: 8-bit AVR (ATmega8535, 8K ROM, 512b RAM)
  • higher-end: 32-bit Tricore (TC1796, 2M ROM, 256K RAM)
slide-10
SLIDE 10

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B

Microcontroller OSEK / AUTOSAR OS

Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

KESO Native Interface (KNI)

  • aspect-oriented mechanism for unsafe interactions
  • full access to the internal state of Java-to-C compiler

Domain Zero (TCB)

GC

slide-11
SLIDE 11

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B

Microcontroller OSEK / AUTOSAR OS

OSEK API (KNI) Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

OSEK Java API

  • access to OSEK / AUTOSAR system services
  • language-based service protection

Domain Zero (TCB)

GC

slide-12
SLIDE 12

stilkerich@cs.fau.de - JTRES ‘10

KESO: Architecture

6

Domain A

System Objects Task B

Microcontroller OSEK / AUTOSAR OS

OSEK API (KNI) Peripheral Device Access (KNI) Control Flows Task A ISR A Task B Task A Resource A

Domain B

Control Flows Task C System Objects Task C

Peripheral Device Access

  • RawMemory (similar to RTSJ)
  • Memory-mapped objects (similar to C structs)

Domain Zero (TCB)

GC

slide-13
SLIDE 13

stilkerich@cs.fau.de - JTRES ‘10

Spatial Isolation

7

 inhibit shared data among different domains  own set of static fields in each domain  logical heap separation (no cross-domain references)

  • current implementation: heaps physically separated

Domain B Domain A

Static Fields Heap Heap Static Fields

slide-14
SLIDE 14

stilkerich@cs.fau.de - JTRES ‘10

Spatial Isolation

7

 inhibit shared data among different domains  own set of static fields in each domain  logical heap separation (no cross-domain references)

  • current implementation: heaps physically separated

 Inter-domain Communication

Domain B Domain A

Static Fields Heap Heap Static Fields

slide-15
SLIDE 15

stilkerich@cs.fau.de - JTRES ‘10

Spatial Isolation

7

 inhibit shared data among different domains  own set of static fields in each domain  logical heap separation (no cross-domain references)

  • current implementation: heaps physically separated

 Inter-domain Communication

  • Shared Memory (≈ RawMemory with reference counting)

Domain B Domain A

Static Fields Heap Heap Static Fields Shared Memory

M M

slide-16
SLIDE 16

stilkerich@cs.fau.de - JTRES ‘10

Spatial Isolation

7

 inhibit shared data among different domains  own set of static fields in each domain  logical heap separation (no cross-domain references)

  • current implementation: heaps physically separated

 Inter-domain Communication

  • Shared Memory (≈ RawMemory with reference counting)
  • Portals (RMI-like mechanism)

Domain B Domain A

Static Fields Heap Service Portal Heap Static Fields Shared Memory

M M

slide-17
SLIDE 17

stilkerich@cs.fau.de - JTRES ‘10

Inter-Domain Communication with Portals

8

 service domain: exports interface as named service

Domain Srv Service name: TickerService interface: TickerService class: TickerServiceImpl TickerService +roundtrip(): void TickerServiceImpl +roundtrip(): void

  • foo(int):void
slide-18
SLIDE 18

stilkerich@cs.fau.de - JTRES ‘10

Inter-Domain Communication with Portals

8

 service domain: exports interface as named service

  • service object is allocated in the service domain

Domain Srv Service name: TickerService interface: TickerService class: TickerServiceImpl TickerService +roundtrip(): void TickerServiceImpl +roundtrip(): void

  • foo(int):void

Service Object

«instance»

slide-19
SLIDE 19

stilkerich@cs.fau.de - JTRES ‘10

Inter-Domain Communication with Portals

8

 service domain: exports interface as named service

  • service object is allocated in the service domain
  • proxy object (portal) is statically allocated for the client domains

Domain Srv Service name: TickerService interface: TickerService class: TickerServiceImpl TickerService +roundtrip(): void TickerServiceImpl +roundtrip(): void

  • foo(int):void

«anonymous» +roundtrip():void

«auto-generated»

Proxy Object

«instance»

Service Object

«instance»

slide-20
SLIDE 20

stilkerich@cs.fau.de - JTRES ‘10

Inter-Domain Communication with Portals

8

 service domain: exports interface as named service

  • service object is allocated in the service domain
  • proxy object (portal) is statically allocated for the client domains

 client domains: statically import this service

  • client domains acquire proxy object reference via name service

Domain Srv Service name: TickerService interface: TickerService class: TickerServiceImpl TickerService +roundtrip(): void TickerServiceImpl +roundtrip(): void

  • foo(int):void

«anonymous» +roundtrip():void

«auto-generated»

Proxy Object

«instance»

Service Object

«instance»

Domain A Portal Domain B Portal

imports

slide-21
SLIDE 21

stilkerich@cs.fau.de - JTRES ‘10

Inter-Domain Communication with Portals

8

 service domain: exports interface as named service

  • service object is allocated in the service domain
  • proxy object (portal) is statically allocated for the client domains

 client domains: statically import this service

  • client domains acquire proxy object reference via name service
  • other domains cannot access the service at runtime

Domain Srv Service name: TickerService interface: TickerService class: TickerServiceImpl TickerService +roundtrip(): void TickerServiceImpl +roundtrip(): void

  • foo(int):void

«anonymous» +roundtrip():void

«auto-generated»

Proxy Object

«instance»

Service Object

«instance»

Domain C Domain A Portal Domain B Portal

imports

slide-22
SLIDE 22

stilkerich@cs.fau.de - JTRES ‘10

Portals: Parameter Passing

 strictly call-by-value

  • retain logical heap separation

 reference parameters

  • deep copy to the service domain’s heap
  • GC needed in the service domain

 marker interface NonCopyable to prevent copying

  • reference replaced by null
  • used for system objects

9

slide-23
SLIDE 23

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); }

slide-24
SLIDE 24

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); }

Name Service

  • compiled to an array lookup
  • returns
  • service object in service domain
  • portal object in client domains
  • null otherwise
slide-25
SLIDE 25

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); }

Portal Call

  • regular virtual method call
slide-26
SLIDE 26

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); } public void roundtrip_portal(object_t *proxy) { domain_t prev_domain = CURRENT_DOMAIN; CURRENT_TASK->effective_domain = DomainSrv_ID; CURRENT_DOMAIN = DomainSrv_ID; PUSH_STACK_PARTITION(DomainSrv_ID); roundtrip_impl(&tickerservice_srvobj); POP_STACK_PARTITION(); CURRENT_DOMAIN = prev_domain; CURRENT_TASK->effective_domain = prev_domain; }

Switch Protection Context

  • backup current domain on stack
  • change current execution context
  • migrate task to service domain
  • restore original domain on return
slide-27
SLIDE 27

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); } public void roundtrip_portal(object_t *proxy) { domain_t prev_domain = CURRENT_DOMAIN; CURRENT_TASK->effective_domain = DomainSrv_ID; CURRENT_DOMAIN = DomainSrv_ID; PUSH_STACK_PARTITION(DomainSrv_ID); roundtrip_impl(&tickerservice_srvobj); POP_STACK_PARTITION(); CURRENT_DOMAIN = prev_domain; CURRENT_TASK->effective_domain = prev_domain; }

Partition Stack

  • enables GC to skip irrelevant partitions
  • only if service method potentially blocks
slide-28
SLIDE 28

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); } public void roundtrip_portal(object_t *proxy) { domain_t prev_domain = CURRENT_DOMAIN; CURRENT_TASK->effective_domain = DomainSrv_ID; CURRENT_DOMAIN = DomainSrv_ID; PUSH_STACK_PARTITION(DomainSrv_ID); roundtrip_impl(&tickerservice_srvobj); POP_STACK_PARTITION(); CURRENT_DOMAIN = prev_domain; CURRENT_TASK->effective_domain = prev_domain; }

Invoke Service Method

  • statically bound call
  • service object is passed as this reference
  • primitive parameters are passed through
  • references are deep copied
slide-29
SLIDE 29

stilkerich@cs.fau.de - JTRES ‘10

Portals: Implementation and Overhead

10

public void foo() { TickerService srv = (TickerService) PortalService.lookup(”TickerService”); srv.roundtrip(); } public void roundtrip_portal(object_t *proxy) { domain_t prev_domain = CURRENT_DOMAIN; CURRENT_TASK->effective_domain = DomainSrv_ID; CURRENT_DOMAIN = DomainSrv_ID; PUSH_STACK_PARTITION(DomainSrv_ID); roundtrip_impl(&tickerservice_srvobj); POP_STACK_PARTITION(); CURRENT_DOMAIN = prev_domain; CURRENT_TASK->effective_domain = prev_domain; }

Cost

  • primitive parameters: same order of magnitude
  • reference parameters: next order(s) of magnitude
slide-30
SLIDE 30

stilkerich@cs.fau.de - JTRES ‘10

Domains compared to Java Isolates (JSR-121)

11

Domains Isolates

isolation concept instantiation runtime representation communication realm-local static fields logical heap separation ealm-local static fields logical heap separation ahead-of-time at runtime none (to the application) instances isolate status lifecycle messages portals shared memory message links inter-JVM mechanisms

slide-31
SLIDE 31

stilkerich@cs.fau.de - JTRES ‘10

Performance: KESO vs. C

12

 Flight Attitude Control Algorithm of the I4Copter

  • http://www4.cs.fau.de/Research/I4Copter
  • C-Code generated from a Simulink Model
  • Input: sensor and steering data
  • Output: engine thrust levels
  • period 9ms
  • Tricore TC1796b MCU @150 MHz (1 MiB MRAM)

 Java port close to the C version  Recorded trace of inflight sensor and steering data

  • Verified that C and Java version output the same actuator values
  • Replayed 200 data samples to measure execution time
slide-32
SLIDE 32

stilkerich@cs.fau.de - JTRES ‘10

Performance: KESO vs. C

12

 Flight Attitude Control Algorithm of the I4Copter

  • http://www4.cs.fau.de/Research/I4Copter
  • C-Code generated from a Simulink Model
  • Input: sensor and steering data
  • Output: engine thrust levels
  • period 9ms
  • Tricore TC1796b MCU @150 MHz (1 MiB MRAM)

 Java port close to the C version  Recorded trace of inflight sensor and steering data

  • Verified that C and Java version output the same actuator values
  • Replayed 200 data samples to measure execution time
slide-33
SLIDE 33

23%

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Execution Times

13

380 µs 400 µs 420 µs 440 µs 460 µs 480 µs 500 µs execution time data set

  • riginal C

KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks)

slide-34
SLIDE 34

5% checks 23%

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Execution Times

13

380 µs 400 µs 420 µs 440 µs 460 µs 480 µs 500 µs execution time data set

  • riginal C

KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks)

slide-35
SLIDE 35

5% checks 18% math 23%

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Execution Times

13

380 µs 400 µs 420 µs 440 µs 460 µs 480 µs 500 µs execution time data set

  • riginal C

KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks)

slide-36
SLIDE 36

5% checks 18% math 23%

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Execution Times

13

380 µs 400 µs 420 µs 440 µs 460 µs 480 µs 500 µs execution time data set

  • riginal C

KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks)

slide-37
SLIDE 37

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Execution Times

14

0.9x 1x 1.1x 1.2x 1.3x

  • verhead factor

Data Set KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks)

constant overhead factor

0.98x 1.04x 1.18x 1.23x

slide-38
SLIDE 38

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Code Size

15

12500 25000

  • riginal C

KESO no checks CMath CMath, no checks

21,866 17,196

code size (bytes) 930b (5.4%) KESO runtime

slide-39
SLIDE 39

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Code Size

15

12500 25000

  • riginal C

KESO no checks CMath CMath, no checks

21,866 17,196 16,610

code size (bytes) 586b (3.5%) checks 930b (5.4%) KESO runtime

slide-40
SLIDE 40

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Code Size

15

12500 25000

  • riginal C

KESO no checks CMath CMath, no checks

21,866 17,196 16,610 23,364

code size (bytes) 586b (3.5%) checks 930b (5.4%) KESO runtime 1.5k (6% ) overhead to C

slide-41
SLIDE 41

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - Code Size

15

12500 25000

  • riginal C

KESO no checks CMath CMath, no checks

21,866 17,196 16,610 23,364 22,778

code size (bytes) 586b (3.5%) checks 930b (5.4%) KESO runtime 1.5k (6% ) overhead to C

slide-42
SLIDE 42

stilkerich@cs.fau.de - JTRES ‘10

Attitude Controller - RAM Usage

16

data bss 600 1200 1800 2400 2,311 997 2,311 997 2,311 101 2,311 101 1,283 977 RAM usage (bytes)

  • riginal C

KESO KESO (no checks) KESO (CMath) KESO (CMath, no checks) 1k heap 896b impure data 20b system objects

slide-43
SLIDE 43

stilkerich@cs.fau.de - JTRES ‘10

Conclusions

 KESO targets the domain of static embedded systems  VM tailoring

  • small overhead of the runtime environment
  • few fixed restrictions to the VM feature set
  • you pay what you need/use

 performance and footprint competitive to C

  • ahead-of-time compilation
  • static analyses

 software-based spatial isolation

17