Materiality and Organizing

25
The Safety-Critical Java Memory Model A Formal Account Ana Cavalcanti Andy Wellings Jim Woodcock University of York IFIP WG 2.3, September 2011 1 / 24

Transcript of Materiality and Organizing

Page 1: Materiality and Organizing

The Safety-Critical Java Memory ModelA Formal Account

Ana Cavalcanti Andy Wellings Jim Woodcock

University of York

IFIP WG 2.3, September 2011

1 / 24

Page 2: Materiality and Organizing

Outline

Safety-Critical Java (SCJ)

Unifying theories of programming (UTP)

Invariants in the UTP

A theory for the Safety-Critical Java memory model

Memory safety

Programming variables and their values

Conclusions

2 / 24

Page 3: Materiality and Organizing

Safety-Critical Java

◮ two languages dominate high-integrity real-time systemsI safer C/C++ subsets — little formal supportI Ada subsets: Spark, Ravenscar profile — Spark Examiner

◮ new development: Safety-Critical Java

◮ international effort lead by the Open Group

◮ performed under Java Community Process

◮ based on RTSJ: Real-Time Specification for Java

3 / 24

Page 4: Materiality and Organizing

Java

◮ all objects placed on heap, scanned by garbage collector

◮ method local variables stored in stack

◮ each thread of control has associated stack

◮ variables and object fields primitive or reference

◮ programmer doesn’t need to worry about memorymanagement

4 / 24

Page 5: Materiality and Organizing

RTSJ

◮ regionalised memory areas for dynamic objects

◮ scoped and immortal memory

◮ object scopes depend on threads

◮ when supporting threads die, objects are collected

◮ immortal objects persist

◮ scope rules forbid dangling references

◮ rule violation is a run-time error

◮ programmer must place object in appropriate scope

◮ tool support required for efficiency and exception-freedom

5 / 24

Page 6: Materiality and Organizing

SCJ

◮ restricts RTSJ use of the heap

◮ annotations for static memory-safety checking

◮ rules & tools by Tang, Plsek, Vitek

◮ non-trivial validation: e.g., overly restrictive rules

◮ independent correctness criteria required◮ contributions?

I informal description: SCJ memory model rationaleI relational memory semanticsI starting point for program development technique

6 / 24

Page 7: Materiality and Organizing

Safety-Critical Java Memory model

◮ safety-critical software spectrum◮ single thread, single processor, simple timing constraint◮ multi-thread, multi-mode, multi-processor◮ three compliance levels◮ level 1: roughly Ravenscar profile◮ mission: bounded set of asynchronous event handlers (ASEHs)◮ sequence of releases◮ periodic: time triggered◮ aperiodic: event triggered◮ safety-critical programming

I no memory allocation during executionI manual allocation too error-proneI garbage collection too complex

◮ SCJ memory modelI safe, predictable dynamic memory managementI restricted scoped memoryI no garbage collection

7 / 24

Page 8: Materiality and Organizing

Application structure

MissionSequencerStart

MissionSelection

MissionInitialisation

MissionExecution

MisionCleanup

Halt

8 / 24

Page 9: Materiality and Organizing

Scoped memory area

I t l MImmortal Memory

Per Mission Memory (a Scoped Memory Area)

X X

X

X

X X

X

Per

Release

Scoped

Per

Release

Scoped

Per

Release

Scoped

XPer

Release

ScopedASEH

1

Memory Memory

ASEH3

Memory

Temporary

Private

Memory

Temporary

ASEH2

Private

Scoped

Memory

Private

Scoped

Memory

ASEH4Valid

object

referencesKey:

Thread Stacks

(one per ASEH and one each

ASEH1

an illegal

referenceX

yfor the mission sequencer and

main program)

I t l MImmortal Memory

Per Mission Memory (a Scoped Memory Area)

X X

X

X

X X

X

Per

Release

Scoped

Per

Release

Scoped

Per

Release

Scoped

XPer

Release

ScopedASEH

1

Memory Memory

ASEH3

Memory

Temporary

Private

Memory

Temporary

ASEH2

Private

Scoped

Memory

Private

Scoped

Memory

ASEH4Valid

object

referencesKey:

Thread Stacks

(one per ASEH and one each

ASEH1

an illegal

referenceX

yfor the mission sequencer and

main program)

I t l MImmortal Memory

Per Mission Memory (a Scoped Memory Area)

X X

X

X

X X

X

Per

Release

Scoped

Per

Release

Scoped

Per

Release

Scoped

XPer

Release

ScopedASEH

1

Memory Memory

ASEH3

Memory

Temporary

Private

Memory

Temporary

ASEH2

Private

Scoped

Memory

Private

Scoped

Memory

ASEH4Valid

object

referencesKey:

Thread Stacks

(one per ASEH and one each

ASEH1

an illegal

referenceX

yfor the mission sequencer and

main program)

I t l MImmortal Memory

Per Mission Memory (a Scoped Memory Area)

X X

X

X

X X

X

Per

Release

Scoped

Per

Release

Scoped

Per

Release

Scoped

XPer

Release

ScopedASEH

1

Memory Memory

ASEH3

Memory

Temporary

Private

Memory

Temporary

ASEH2

Private

Scoped

Memory

Private

Scoped

Memory

ASEH4Valid

object

referencesKey:

Thread Stacks

(one per ASEH and one each

ASEH1

an illegal

referenceX

yfor the mission sequencer and

main program)

.. SCJ Memory Areas

9 / 24

Page 10: Materiality and Organizing

hiJaC: High Integrity Java Applications in Circus

◮ Five-year project

◮ First effort to formalise the SCJ paradigm

◮ Highly constrained programming architecture

◮ Java is a vehicle

◮ Paradigm not identified

◮ Circus family: Z and CSP + time + object-orientation

◮ Semantic model: UTP

10 / 24

Page 11: Materiality and Organizing

Unifying theories of programming

◮ Relational predicative model: alphabetised predicates

◮ Combination of paradigms

◮ Refinement

Theories

◮ Observational variables (and their dashed counterparts)

◮ Healthiness conditions

◮ Relations: x ′ > x

◮ Designs: (x > 0 ⊢ x ′ = x + 1)

11 / 24

Page 12: Materiality and Organizing

Designs

Theory

◮ Pre and postcondition specifications

◮ Observational variables: ok and ok ′

◮ (P ⊢ Q) =̂ (ok ∧ P ⇒ ok ′ ∧ Q)

Design healthiness conditions

H1 P = ok ⇒ P

H2 P = P ; J where J =̂ (ok ⇒ ok ′) ∧ v ′ = v

Every design D can be written as (¬ D f ⊢ D t)

Db =̂ D [b/ok ′]

12 / 24

Page 13: Materiality and Organizing

Invariants in the UTP

Operation invariants P ⊢ Q ∧ Ψ

OIH(Ψ) D = D ∧ (ok ∧ ¬ D f ⇒ Ψ)

State invariants (P ∧ ψ ⊢ Q ∧ ψ′)

ISH(ψ) D = D ∨ (ok ∧ ¬ D f ∧ ψ ⇒ ok ′ ∧ D t)

OSH(ψ) D = D ∧ (ok ∧ ¬ D f ∧ ψ ⇒ ψ′)

SIH(ψ) =̂ ISH(ψ) ◦ OSH(ψ)

13 / 24

Page 14: Materiality and Organizing

Type Definitions

◮ program, mission sequencer, event handlers: stacks of frames

◮ frames: execution context for methods

◮ variables: VName

◮ values are primitive values or references:Value = PValue ∪ Ref

◮ null : a primitive value

◮ Frame = VName 7→ Value

◮ mission handlers: HName

14 / 24

Page 15: Materiality and Organizing

Type Definitions

◮ references in a frame: refsInF (f ) = ran(f ◃ Ref )

◮ object values: OValue = VName 7→ Value

◮ memory contents: MAreaC = Ref 7→ OValue

◮ references to resident objects in a memory area:

refsRes(ma) = domma

◮ references in a memory area:

refsInMA(ma)= { r : Ref | ∃ r ′ : refsRes(ma) • r ∈ ran(ma(r ′)) }

◮ profile maps resident references to their object fields

◮ profile : MAreaC → (Ref 7→ FVName)

profile(ma) = { r : domma • r 7→ dom(ma(r)) }

15 / 24

Page 16: Materiality and Organizing

A theory for the SCJ memory model

Alphabet

◮ pStack ,msStack : stackFrame

◮ handlers : FHName

◮ hStack : handlers → stackFrame

◮ immortal ,mission : MAreaC

◮ perR : handlers → MAreaC

◮ tPriv : handlers → stackMAreaC

.. Diagram

Types

◮ Frame = VName 7→ Value

◮ MAreaC = Ref 7→ OValue

16 / 24

Page 17: Materiality and Organizing

Healthiness conditions

Objects only ever added to immortal memory

HSCJ1 =̂ OIH(profile(immortal) ⊆ profile(immortal ′))

Program stack related to immortal memory

HSCJ2 =̂ SIH(refsIn(pStack) ⊆ refsRes(immortal))

Immortal memory is closed

HSCJ3 =̂ SIH(refsIn(immortal) ⊆ refsRes(immortal))

17 / 24

Page 18: Materiality and Organizing

Healthiness conditions

Objects only ever added to immortal memory

HSCJ1 =̂ OIH(profile(immortal) ⊆ profile(immortal ′))

Sequencer stack related to immortal and mission memory

HSCJ4 =̂ SIH(refsIn(msStack) ⊆ refsRes({immortal ,mission}))

Mission memory is closed

HSCJ5 =̂ SIH(refsIn(mission) ⊆ refsRes({immortal ,mission}))

17 / 24

Page 19: Materiality and Organizing

Healthiness conditions

Similar for the other stacks and memory areas.Profile of mission, per release, and temporary private areas

◮ We cannot relate mission and mission ′, for instance.

◮ History variables

◮ Similar to timed model

Memory areas are disjoint

HSCJ9 =̂

SIH

disjoint

⟨refsRes immortal , refsRes mission⟩a seqPR(perR)a seqTP(tPriv)

◮ seqPR(perR)/seqTP(tPriv): sequences of sets of referencesresiding in per-release/temporary private memory

18 / 24

Page 20: Materiality and Organizing

Memory safety

x r2

b r3

z 2

y r1

ff

f

1

2 x r2

b r3

2

y r1

ff

f

1

2

m r3

n r4

r2

m

1

1s

x r3r1

m2

u null

v r5

r3

c 6r5 w r2

.. Stack-areas Example

19 / 24

Page 21: Materiality and Organizing

Memory safety

Regions and dangling references

◮ Frame = VName 7→ Value

◮ MAreaC = Ref 7→ OValue

◮ OValue = VName 7→ Value

regionRefs(rs,mas) = (((∪

mas) o9 ran)◃ Ref )∗(| rs |)

regionFrame(f ,mas) = regionRefs(refsInF (f ),mas)region(sf ,mas) =

∪{ f : sf • regionFrame(f ,mas) }

noDangRef (sf ,mas) = (region(sf ,mas) ⊆ refsRes(mas))

r1

r3r3

r2

r5

r4

20 / 24

Page 22: Materiality and Organizing

Memory safety

Healthiness conditions

HMS1 =̂ SIH(noDangRef (pStack , {immortal}))

HMS2 =̂ SIH(noDangRef (msStack , {immortal ,mission}))

HMS3 =̂ SIH(∀ h : handlers • noDangRef (hStack(h),mas))where mas = {immortal ,mission, perR(h) } ∪ ran(tPriv(h))

Theorem: Every SCJ-healthy predicate is HMS-healthy

21 / 24

Page 23: Materiality and Organizing

Programming variables and their values

The AVS model

◮ A: valid addresses

◮ V : values of terminals

◮ S : sharing relation

.. Example

Example: x

◮ Addresses: x , x .m, x .n, x .m.u, and so on.

◮ Values of terminals: x .m.u is null , x .m.v .c is 6, and so on.

22 / 24

Page 24: Materiality and Organizing

Programming variables and their values

Healthiness conditions

HV1 =̂ SIH(∧

v : vars(pStack) • v = !(v , pStack , {immortal}))

HV2 =̂ SIH

( ∧v : vars(msStack) •v = !(v ,msStack , {immortal ,mission})

)HV3 =̂

SIH

∀ h : handlers •∧

v : vars(hStack h) •

v = !

(v , hStack h,{immortal ,mission, perR h} ∪ ran(tPriv h)

)

23 / 24

Page 25: Materiality and Organizing

Conclusions and future work

◮ First formalisation of the SCJ memory model

◮ Essential ingredient for reasoning by refinement

◮ General results on UTP theories

Future work

◮ Connections to other theories

◮ Extension to Circus

◮ Refinement laws and strategies

24 / 24