Translating Java bytecode to BoogiePL
|
|
|
- Griffin Montgomery
- 5 years ago
- Views:
Transcription
1 Recap Changes Coq Boogie Conclusion Master project - Final presentation September 29, 2006
2 Recap Changes Coq Boogie Conclusion Outline Recap What has changed? Formalization of the translation Boogie modifications Conclusion
3 Recap Changes Coq Boogie Conclusion Overview Example What is this project about?
4 Recap Changes Coq Boogie Conclusion Overview Example What is this project about? Providing a translation from bytecode to BoogiePL
5 Recap Changes Coq Boogie Conclusion Overview Example What is this project about? Providing a translation from bytecode to BoogiePL Including exceptions
6 Recap Changes Coq Boogie Conclusion Overview Example What is this project about? Providing a translation from bytecode to BoogiePL Including exceptions Formalizing the translation in Coq
7 Recap Changes Coq Boogie Conclusion Overview Example What is this project about? Providing a translation from bytecode to BoogiePL Including exceptions Formalizing the translation in Coq Basis for a soundness proof
8 Recap Changes Coq Boogie Conclusion Overview Example What is this project about? Providing a translation from bytecode to BoogiePL Including exceptions Formalizing the translation in Coq Basis for a soundness proof Extending Boogie to support exceptions
9 Recap Changes Coq Boogie Conclusion Overview Example Translating an example Java source public class Account { private int balance; public void deposit(int amount) { balance = balance + amount; } }
10 Recap Changes Coq Boogie Conclusion Overview Example Translating an example Java source public class Account { private int balance; public void deposit(int amount) { balance = balance + amount; } } JVM bytecode public void deposit(int); 0: aload_0 1: aload_0 2: getfield #2; //Field balance:i 5: iload_1 6: iadd 7: putfield #2; //Field balance:i 10: return
11 Recap Changes Coq Boogie Conclusion Overview Example Translating an example (cont d) implementation Account.deposit(this: ref, param1: int) { init : assume this null typ(rval(this)) = Account; reg0r := this ; // argument to register transfer reg1i := param1; goto block 0; block 0: stack0r := reg0r ; // aload 0 stack1r := reg0r ; // aload 0 stack1i := toint (get(heap, fieldloc ( stack1r, Account.balance ))); stack2i := reg1i ; // iload 1 stack1i := stack1i + stack2i; // iadd heap := update(heap, fieldloc ( stack0r, Account.balance), ival ( stack1i )); return; }
12 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Overview What has changed?
13 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Overview What has changed? Simplified translation
14 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Overview What has changed? Simplified translation Revised heap axiomatization
15 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Overview What has changed? Simplified translation Revised heap axiomatization Method frame conditions
16 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Overview What has changed? Simplified translation Revised heap axiomatization Method frame conditions Static fields and methods
17 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Simplified translation Generic stack manipulation instructions (e.g. dup, swap) relied on type of stack elements.
18 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Simplified translation Generic stack manipulation instructions (e.g. dup, swap) relied on type of stack elements. Unnecessary complexity // dup stack(h + 1)[stackType(h)] := stack(h)[stacktype(h)];
19 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Simplified translation Generic stack manipulation instructions (e.g. dup, swap) relied on type of stack elements. Unnecessary complexity // dup stack(h + 1)[stackType(h)] := stack(h)[stacktype(h)]; Solution: just perform operation on all types // dup stack(h + 1)i := stack(h)i; // primitive stack(h + 1)r := stack(h)r; // reference
20 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Heap axiomatization Still based on Poetzsch-Heffter formalization, but...
21 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Heap axiomatization Still based on Poetzsch-Heffter formalization, but... Support for arrays function fieldloc ( ref, name) returns (Location); function arrayloc( ref, int) returns (Location);
22 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Heap axiomatization Still based on Poetzsch-Heffter formalization, but... Support for arrays function fieldloc ( ref, name) returns (Location); function arrayloc( ref, int) returns (Location); Data model closer to Java (uses values now, not objects) function update(store, Location, Value) returns (Store ); function add(store, Allocation ) returns (Store ); function get(store, Location) returns (Value); function alive (Value, Store) returns (bool); function new(store, Allocation ) returns (Value);
23 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Method invocation Previously heap variable was havoced and heap state was lost.
24 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Method invocation Previously heap variable was havoced and heap state was lost. Now we preserve the heap state in a variable pre heap := heap; // preserve heap havoc heap;
25 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Method invocation Previously heap variable was havoced and heap state was lost. Now we preserve the heap state in a variable pre heap := heap; // preserve heap havoc heap; Values that were alive in the preheap remain alive assume ( v: Value alive(v, pre heap) alive(v, heap));
26 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Method invocation Previously heap variable was havoced and heap state was lost. Now we preserve the heap state in a variable pre heap := heap; // preserve heap havoc heap; Values that were alive in the preheap remain alive assume ( v: Value alive(v, pre heap) alive(v, heap)); Locations not in callee modifies remain unchanged assume ( h: Store, l: Location, v:value l Account.balance get(heap, l ) = get(pre heap, l));
27 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Static fields and methods Added support for static fields and methods.
28 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Static fields and methods Added support for static fields and methods. Static fields: Introduce type object function typeobject(t : name) returns (ref); axiom ( t: name typeobject(t) null); // getstatic int C.f stack(h + 1)i := toint(get(heap, fieldloc(typeobject(c), C.f)));
29 Recap Changes Coq Boogie Conclusion Simplications Heap Methods Static members Static fields and methods Added support for static fields and methods. Static fields: Introduce type object function typeobject(t : name) returns (ref); axiom ( t: name typeobject(t) null); // getstatic int C.f stack(h + 1)i := toint(get(heap, fieldloc(typeobject(c), C.f))); Treat static methods same as instance, just omit implicit this parameter
30 Recap Changes Coq Boogie Conclusion Introduction Layout Example Formalization in Coq I have produced a formalization in Coq, a theorem prover.
31 Recap Changes Coq Boogie Conclusion Introduction Layout Example Formalization in Coq I have produced a formalization in Coq, a theorem prover. Includes formalization of BoogiePL language
32 Recap Changes Coq Boogie Conclusion Introduction Layout Example Formalization in Coq I have produced a formalization in Coq, a theorem prover. Includes formalization of BoogiePL language Depends on bytecode formalization library Bicolano
33 Recap Changes Coq Boogie Conclusion Introduction Layout Example Formalization in Coq I have produced a formalization in Coq, a theorem prover. Includes formalization of BoogiePL language Depends on bytecode formalization library Bicolano Type-checkable guarantees syntactically correct BoogiePL
34 Recap Changes Coq Boogie Conclusion Introduction Layout Example Formalization in Coq I have produced a formalization in Coq, a theorem prover. Includes formalization of BoogiePL language Depends on bytecode formalization library Bicolano Type-checkable guarantees syntactically correct BoogiePL Basis for a soundness proof
35 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development:
36 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development: BoogiePL.v: Formalization of BoogiePL language
37 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development: BoogiePL.v: Formalization of BoogiePL language Basically a description of the grammar
38 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development: BoogiePL.v: Formalization of BoogiePL language Basically a description of the grammar BoogieUtils.v: Helper library for building expressions
39 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development: BoogiePL.v: Formalization of BoogiePL language Basically a description of the grammar BoogieUtils.v: Helper library for building expressions Grammar makes it hard to create expressions directly
40 Recap Changes Coq Boogie Conclusion Introduction Layout Example Layout of development Layout of Coq development: BoogiePL.v: Formalization of BoogiePL language Basically a description of the grammar BoogieUtils.v: Helper library for building expressions Grammar makes it hard to create expressions directly Translation.v: Translation of bytecode methods to BoogiePL programs
41 Recap Changes Coq Boogie Conclusion Introduction Layout Example Example: Translating swap Definition TrInstruction (bm: BytecodeMethod) (pc: PC) (cur: Boogie.Block) : ( list Boogie.Block Boogie.Block) := match BYTECODEMETHOD.instructionAt bm pc with... Swap match cur with ( blockid, cmds,toc) (blockid, cmds++( Assign (swapvar Ref) (BPL.IdentExpr (stvar (h 1) Ref)):: Assign (swapvar Int) (BPL.IdentExpr (stvar (h 1) Int)):: Assign ( stvar (h 1) Ref) (BPL.IdentExpr (stvar h Ref)):: Assign ( stvar (h 1) Int) (BPL.IdentExpr (stvar h Int )):: Assign ( stvar h Ref) (BPL.IdentExpr (swapvar Ref )):: Assign ( stvar h Int ) (BPL.IdentExpr (swapvar Int )):: nil )) end...
42 Recap Changes Coq Boogie Conclusion Introduction Layout Example Example: Boogie declarations ( Declarations ) Inductive Declaration : Set := TypeDecl (ids : list Identifier ) ConstantDecl ( idtypes : list ( Identifier BPLType)) FunctionDecl ( ids : list Identifier ) (params: list (option Identifier BPLType)) AxiomDecl (e: Expression) VariableDecl ( idtypes : list ( Identifier BPLType)) ProcedureDecl (id : Identifier ) (params: list ( Identifier BPLType)) (returntype: option BPLType) (specs: list Specification ) ImplementationDecl (id : Identifier ) (params: list ( Identifier BPLType)) (returntype: option BPLType) (body: Body).
43 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions
44 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions Modifications to incorporate our methdology
45 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions Modifications to incorporate our methdology Code in catch blocks
46 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions Modifications to incorporate our methdology Code in catch blocks Exceptional method termination
47 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions Modifications to incorporate our methdology Code in catch blocks Exceptional method termination Throwing exceptions
48 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Boogie modifications: Overview Boogie does not translate exceptions Modifications to incorporate our methdology Code in catch blocks Exceptional method termination Throwing exceptions New commandline switch /experimentalexceptions
49 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: Before
50 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: Before CFG contains information about catch blocks
51 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: Before CFG contains information about catch blocks catch handlers are exceptional successors of other nodes
52 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: Before CFG contains information about catch blocks catch handlers are exceptional successors of other nodes But: translation only considers normal successors
53 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: After
54 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: After Exceptional successors are no longer ignored
55 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Code in catch blocks: After Exceptional successors are no longer ignored catch ( InsufficientFundsException ) translates to block [catch]: havoc stack0o; assume cast(heap[stack0o, allocated ], bool) = true stack0o null typeof(stack0o) <: InsufficientFundsException ; // branch to handler code goto block [handler];
56 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before
57 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before call statement desugars into a state command
58 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before call statement desugars into a state command Corresponds to a let-binding, own set of local variables
59 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before call statement desugars into a state command Corresponds to a let-binding, own set of local variables Methods are assumed to always terminate normally
60 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before call statement desugars into a state command Corresponds to a let-binding, own set of local variables Methods are assumed to always terminate normally No additional blocks/execution paths generated
61 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: Before call statement desugars into a state command Corresponds to a let-binding, own set of local variables Methods are assumed to always terminate normally No additional blocks/execution paths generated Desugar[[result := call C.m(x,y)]] := { var call@formal@0: int, call@formal@1: int ; call@formal@0 := x; call@formal@1 := y; } assert Precondition(C.m, prestate); havoc Heap, result; assume Postcondition(C.m, prestate, poststate);
62 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early
63 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early Split desugaring over multiple blocks
64 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early Split desugaring over multiple blocks Successor blocks for normal and exceptional execution
65 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early Split desugaring over multiple blocks Successor blocks for normal and exceptional execution Spec# doesn t have exceptional postcondtions yet
66 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early Split desugaring over multiple blocks Successor blocks for normal and exceptional execution Spec# doesn t have exceptional postcondtions yet Exceptional case not really useful right now
67 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After Desugar call statement early Split desugaring over multiple blocks Successor blocks for normal and exceptional execution Spec# doesn t have exceptional postcondtions yet Exceptional case not really useful right now throws clause not serialized ( next release)
68 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Method invocation: After (cont d) block 2042: call@formal@0 := x; call@formal@1 := y; call@old@heap := Heap; assert Precondition(C.m, prestate); havoc Heap, result; goto block 2042 N, block 2042 X; block 2042 N: // normal termination assume Postcondition(C.m, prestate, poststate);... // normal continuation block 2042 X: // exceptional termination assume ExcpPostcondition(C.m, prestate, poststate); goto block [handler];
69 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: Before
70 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: Before Throwing an exception generates the following code: assert stack(h)r null; assume false; //! return;
71 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: Before Throwing an exception generates the following code: assert stack(h)r null; assume false; //! return; After an assume false; Boogie will verify anything, postcondition violations are ignored.
72 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: After Case distinction:
73 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: After Case distinction: Exception is caught (fully or partially): assert stack(h)r null; goto block [handler];
74 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Throwing exceptions: After Case distinction: Exception is caught (fully or partially): assert stack(h)r null; goto block [handler]; No handler: old behavior (no exceptional postconditions yet) assert stack(h)r null; assume false; return;
75 Recap Changes Coq Boogie Conclusion Overview Catch blocks Method calls Throwing exceptions D Demo public static void transfer (Account! src, Account! dest, int amount) requires amount > 0; throws TransferFailedException { try { src. withdraw(amount); } catch ( InsufficientFundsException e) { throw new TransferFailedException(); } dest. deposit(amount); }
76 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced:
77 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced: Translation of Java bytecode to BoogiePL, including exceptions
78 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced: Translation of Java bytecode to BoogiePL, including exceptions BoogiePL version of the Poetzsch-Heffter heap model with support for arrays
79 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced: Translation of Java bytecode to BoogiePL, including exceptions BoogiePL version of the Poetzsch-Heffter heap model with support for arrays Formalization of the translation for the Coq theorem prover
80 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced: Translation of Java bytecode to BoogiePL, including exceptions BoogiePL version of the Poetzsch-Heffter heap model with support for arrays Formalization of the translation for the Coq theorem prover Basis for a soundness proof
81 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Conclusion This project produced: Translation of Java bytecode to BoogiePL, including exceptions BoogiePL version of the Poetzsch-Heffter heap model with support for arrays Formalization of the translation for the Coq theorem prover Basis for a soundness proof Boogie modifications for our approach of dealing with exceptions
82 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Future work
83 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Future work Support for floating-point numbers
84 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Future work Support for floating-point numbers Axiomatization in Boogie needed.
85 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Future work Support for floating-point numbers Axiomatization in Boogie needed. Implementation of the translation (use JML suite?)
86 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Future work Support for floating-point numbers Axiomatization in Boogie needed. Implementation of the translation (use JML suite?) Exception methodology for Spec# (exceptional postconditions)
87 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Questions???
88 Recap Changes Coq Boogie Conclusion Conclusion Future work Thanks Sushi apéro Sushi RZ F11, Feel free to join!
89 Example translations Frame conditions Exceptional postconditions Frame conditions // requires amount > 0; // modifies this. balance; // ensures balance + amount == old(balance); // when InsufficientFundsException ensures balance == old(balance); public void withdraw(int amount) throws InsufficientFundsException {... } public static void transfer (Account src, Account dest, int amount) { try { src. withdraw(amount); } catch ( InsufficientFundsException e) {... }... }
90 Example translations Frame conditions Exceptional postconditions Frame conditions (cont d) assume (forall v: Value alive(v, pre heap) alive(v, heap)); assume (forall h: Store, l : Location, v:value l fieldloc(arg0r, Account.balance) get(heap, l) = get(pre heap, l)); goto block 2 N, block 2 InsufficientFundsException ; block 2 N: assume stack1i > 0 // normal postcondition toint (get(heap, fieldloc ( arg0r, Account.balance))) + stack1i = toint(get(pre heap, fieldloc ( arg0r, Account.balance )));... block 2 InsufficientFundsException : havoc stack0r; // exceptional postcondition assume alive( rval ( stack0r ), heap); assume typ(rval(stack0r)) <: InsufficientFundsException ; assume true get(pre heap, fieldloc(arg0r, Account.balance)) = get(heap, fieldloc ( arg0r, Account.balance));...
91 Example translations Frame conditions Exceptional postconditions Normal and exceptional postconditions Normal and exceptional postconditions: // ensures balance + amount == old(balance); // when InsufficientFundsException ensures balance == old(balance); public void withdraw(int amount) {...} post: // old( this.balance) == this.balance + param1 assert toint (get(old heap, fieldloc ( this, Account.balance))) == toint (get(heap, fieldloc ( this, Account.balance))) + param1; return; post X InsufficientFundsException : // old( this. balance) == this.balance assert toint (get(heap, fieldloc ( this, Account.balance))) == toint (get(old heap, fieldloc ( this, Account.balance ))); return; }
Automated Program Verifier for Java Bytecode. Samuel Willimann
Automated Program Verifier for Java Bytecode Samuel Willimann Master Project Report Software Component Technology Group Department of Computer Science ETH Zurich http://sct.inf.ethz.ch/ 3/5/2007-9/4/2007
Static Program Analysis
Static Program Analysis Thomas Noll Software Modeling and Verification Group RWTH Aachen University https://moves.rwth-aachen.de/teaching/ws-1617/spa/ Recap: Taking Conditional Branches into Account Extending
Motivation. Correct and maintainable software Cost effective software production Implicit assumptions easily broken
Spec# Andreas Vida Motivation Correct and maintainable software Cost effective software production Implicit assumptions easily broken Need more formal f specification Integration into a popular language
Program Verification (6EC version only)
Program Verification (6EC version only) Erik Poll Digital Security Radboud University Nijmegen Overview Program Verification using Verification Condition Generators JML a formal specification language
Certified Memory Usage Analysis
Certified Memory Usage Analysis David Cachera, Thomas Jensen, David Pichardie, Gerardo Schneider IRISA, ENS Cachan Bretagne, France Context Embedded devices (smart cards, mobile phones) memory is limited
CSE P 501 Compilers. Java Implementation JVMs, JITs &c Hal Perkins Winter /11/ Hal Perkins & UW CSE V-1
CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Winter 2008 3/11/2008 2002-08 Hal Perkins & UW CSE V-1 Agenda Java virtual machine architecture.class files Class loading Execution engines
Formal Specification and Verification
Formal Specification and Verification Proof Obligations Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification and Verification:
A Verifying Compiler for a Multi-threaded Object-Oriented Language
K. R. M. Leino and W. Schulte / A Verifying Compiler 1 A Verifying Compiler for a Multi-threaded Object-Oriented Language K. Rustan M. Leino and Wolfram Schulte Microsoft Research,Redmond, WA, USA e-mail:
CS2110 Fall 2011 Lecture 25. Under the Hood: The Java Virtual Machine, Part II
CS2110 Fall 2011 Lecture 25 Under the Hood: The Java Virtual Machine, Part II 1 Java program last time Java compiler Java bytecode (.class files) Compile for platform with JIT Interpret with JVM run native
Agenda. CSE P 501 Compilers. Java Implementation Overview. JVM Architecture. JVM Runtime Data Areas (1) JVM Data Types. CSE P 501 Su04 T-1
Agenda CSE P 501 Compilers Java Implementation JVMs, JITs &c Hal Perkins Summer 2004 Java virtual machine architecture.class files Class loading Execution engines Interpreters & JITs various strategies
Object Ownership in Program Verification
Object Ownership in Program Verification Werner Dietl 1 and Peter Müller 2 1 University of Washington wmdietl@cs.washington.edu 2 ETH Zurich peter.mueller@inf.ethz.ch Abstract. Dealing with aliasing is
Lecture 10 Design by Contract
CS 5959 Writing Solid Code Fall 2015 Nov-23 Lecture 10 Design by Contract Zvonimir Rakamarić University of Utah Design by Contract Also called assume-guarantee reasoning Developers annotate software components
Compositional Cutpoint Verification
Compositional Cutpoint Verification Eric Smith (Stanford University) Collaborators: David Dill (Stanford University) David Hardin (Rockwell Collins) Contact ewsmith@stanford.edu Background Based on A Symbolic
BOOGIE. Presentation by Itsik Hefez A MODULAR REUSABLE VERIFIER FOR OBJECT-ORIENTED PROGRAMS MICROSOFT RESEARCH
BOOGIE A MODULAR REUSABLE VERIFIER FOR OBJECT-ORIENTED PROGRAMS MICROSOFT RESEARCH Presentation by Itsik Hefez Introduction Boogie is an intermediate verification language, intended as a layer on which
Compiling Techniques
Lecture 10: Introduction to 10 November 2015 Coursework: Block and Procedure Table of contents Introduction 1 Introduction Overview Java Virtual Machine Frames and Function Call 2 JVM Types and Mnemonics
Proof Carrying Code(PCC)
Discussion p./6 Proof Carrying Code(PCC Languaged based security policy instead of OS-based A mechanism to determine with certainity that it is safe execute a program or not Generic architecture for providing
Automatic Verification of Computer Programs
Chair of Software Engineering Automatic Verification of Computer Programs these slides contain advanced material and are optional What is verification Check correctness of the implementation given the
Code Generation. Frédéric Haziza Spring Department of Computer Systems Uppsala University
Code Generation Frédéric Haziza Department of Computer Systems Uppsala University Spring 2008 Operating Systems Process Management Memory Management Storage Management Compilers Compiling
The Java Language Implementation
CS 242 2012 The Java Language Implementation Reading Chapter 13, sections 13.4 and 13.5 Optimizing Dynamically-Typed Object-Oriented Languages With Polymorphic Inline Caches, pages 1 5. Outline Java virtual
Formal Systems II: Applications
Formal Systems II: Applications Functional Verification of Java Programs: Java Dynamic Logic Bernhard Beckert Mattias Ulbrich SS 2017 KIT INSTITUT FÜR THEORETISCHE INFORMATIK KIT University of the State
Static program checking and verification
Chair of Software Engineering Software Engineering Prof. Dr. Bertrand Meyer March 2007 June 2007 Slides: Based on KSE06 With kind permission of Peter Müller Static program checking and verification Correctness
Why. an intermediate language for deductive program verification
Why an intermediate language for deductive program verification Jean-Christophe Filliâtre CNRS Orsay, France AFM workshop Grenoble, June 27, 2009 Jean-Christophe Filliâtre Why tutorial AFM 09 1 / 56 Motivations
Fundamentals of Software Engineering
Fundamentals of Software Engineering Reasoning about Programs - Selected Features Ina Schaefer Institute for Software Systems Engineering TU Braunschweig, Germany Slides by Wolfgang Ahrendt, Richard Bubel,
Programming with Contracts. Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany
Programming with Contracts Juan Pablo Galeotti, Alessandra Gorla Saarland University, Germany Contract A (formal) agreement between Method M (callee) Callers of M Rights Responsabilities Rights Responsabilities
School of Computer & Communication Sciences École Polytechnique Fédérale de Lausanne
Principles of Dependable Systems Building Reliable Software School of Computer & Communication Sciences École Polytechnique Fédérale de Lausanne Winter 2006-2007 Outline Class Projects: mtgs next week
An Introduction to Multicodes. Ben Stephenson Department of Computer Science University of Western Ontario
An Introduction to Multicodes Ben Stephenson Department of Computer Science University of Western Ontario ben@csd csd.uwo.ca Outline Java Virtual Machine Background The Current State of the Multicode Art
Course Overview. PART I: overview material. PART II: inside a compiler. PART III: conclusion
Course Overview PART I: overview material 1 Introduction (today) 2 Language Processors (basic terminology, tombstone diagrams, bootstrapping) 3 The architecture of a Compiler PART II: inside a compiler
Run-time Program Management. Hwansoo Han
Run-time Program Management Hwansoo Han Run-time System Run-time system refers to Set of libraries needed for correct operation of language implementation Some parts obtain all the information from subroutine
Compiler construction 2009
Compiler construction 2009 Lecture 2 Code generation 1: Generating Jasmin code JVM and Java bytecode Jasmin Naive code generation The Java Virtual Machine Data types Primitive types, including integer
Verifying JML specifications with model fields
Verifying JML specifications with model fields Cees-Bart Breunesse and Erik Poll Department of Computer Science, University of Nijmegen Abstract. The specification language JML (Java Modeling Language)
Java Modeling Language (JML)
CIS 771: Software Specifications Introduction to JML Java Modeling Language (JML) A behavioral interface specification language for Java supporting design-by-contract (DBC)... invented by Gary T. Leavens
AP COMPUTER SCIENCE JAVA CONCEPTS IV: RESERVED WORDS
AP COMPUTER SCIENCE JAVA CONCEPTS IV: RESERVED WORDS PAUL L. BAILEY Abstract. This documents amalgamates various descriptions found on the internet, mostly from Oracle or Wikipedia. Very little of this
CSE 431S Final Review. Washington University Spring 2013
CSE 431S Final Review Washington University Spring 2013 What You Should Know The six stages of a compiler and what each stage does. The input to and output of each compilation stage (especially the back-end).
objects
/*@ immutable @*/ objects Erik Poll SoS group (aka the LOOP group) Radboud University Nijmegen KeY workshop June 2005 yet another JML keyword... Java provides final ie. immutable - fields What about immutable
CS 3 Introduction to Software Engineering. 3: Exceptions
CS 3 Introduction to Software Engineering 3: Exceptions Questions? 2 Objectives Last Time: Procedural Abstraction This Time: Procedural Abstraction II Focus on Exceptions. Starting Next Time: Data Abstraction
Overview The Java Modeling Language (Part 1) Related Work
Overview The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
JML tool-supported specification for Java Erik Poll Radboud University Nijmegen
JML tool-supported specification for Java Erik Poll Radboud University Nijmegen Erik Poll - JML p.1/41 Overview The specification language JML Tools for JML, in particular runtime assertion checking using
Proving well-formedness of interface specifications. Geraldine von Roten
Proving well-formedness of interface specifications Geraldine von Roten Master Project Report Software Component Technology Group Department of Computer Science ETH Zurich http://sct.inf.ethz.ch/ Fall/2007
Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen
Introduction to JML David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2 & JML Tutorial p.1/30
JML Class Specifications The Java Modeling Language (Part 2) A Java Class
JML Class Specifications The Java Modeling Language (Part 2) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria
JVML Instruction Set. How to get more than 256 local variables! Method Calls. Example. Method Calls
CS6: Program and Data Representation University of Virginia Computer Science Spring 006 David Evans Lecture 8: Code Safety and Virtual Machines (Duke suicide picture by Gary McGraw) pushing constants JVML
CSCE 314 Programming Languages. Type System
CSCE 314 Programming Languages Type System Dr. Hyunyoung Lee 1 Names Names refer to different kinds of entities in programs, such as variables, functions, classes, templates, modules,.... Names can be
The Java Modeling Language (Part 2)
The Java Modeling Language (Part 2) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
JVM. What This Topic is About. Course Overview. Recap: Interpretive Compilers. Abstract Machines. Abstract Machines. Class Files and Class File Format
Course Overview What This Topic is About PART I: overview material 1 Introduction 2 Language processors (tombstone diagrams, bootstrapping) 3 Architecture of a compiler PART II: inside a compiler 4 Syntax
The Java Modeling Language JML
The Java Modeling Language JML Néstor Cataño ncatano@puj.edu.co Faculty of Engineering Pontificia Universidad Javeriana The Java Modelling Language JML p.1/47 Lecture Plan 1. An Introduction to JML 2.
Relation Overriding. Syntax and Semantics. Simple Semantic Domains. Operational Semantics
SE3E03, 2006 1.59 61 Syntax and Semantics Syntax Shape of PL constructs What are the tokens of the language? Lexical syntax, word level How are programs built from tokens? Mostly use Context-Free Grammars
Formal Methods for Software Development
Formal Methods for Software Development Java Modeling Language, Part I Wolfgang Ahrendt 04 October 2018 FMSD: Java Modeling Language /GU 181004 1 / 36 Role of JML in the Course programming/modelling property/specification
Formale Entwicklung objektorientierter Software
Formale Entwicklung objektorientierter Software Praktikum im Wintersemester 2008/2009 Prof. P. H. Schmitt Christian Engel, Benjamin Weiß Institut für Theoretische Informatik Universität Karlsruhe 5. November
The Boogie Intermediate Language
The Boogie Intermediate Language What is BoogiePL? A simplified C-like language that s structured for verification tasks Has constructs that allow specification of assumptions and axioms, as well as assertions
Reasoning about Object Structures Using Ownership
Reasoning about Object Structures Using Ownership Peter Müller ETH Zurich, Switzerland Peter.Mueller@inf.ethz.ch Abstract. Many well-established concepts of object-oriented programming work for individual
Under the Hood: The Java Virtual Machine. Lecture 23 CS2110 Fall 2008
Under the Hood: The Java Virtual Machine Lecture 23 CS2110 Fall 2008 Compiling for Different Platforms Program written in some high-level language (C, Fortran, ML,...) Compiled to intermediate form Optimized
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen
Assertions & Design-by-Contract using JML Erik Poll University of Nijmegen Erik Poll - JML p.1/39 Overview Assertions Design-by-Contract for Java using JML Contracts and Inheritance Tools for JML Demo
Today. Homework. Lecture Notes CPSC 224 (Spring 2012) Quiz 5. interfaces. exceptions. best practices. start on swing (if time) hw3 due
Today Quiz 5 interfaces exceptions best practices start on swing (if time) Homework hw3 due hw4 out (next thurs) S. Bowers 1 of 8 Implicit vs. Explicit Parameters Methods define their explicit parameters
UNIT 3
UNIT 3 Presentation Outline Sequence control with expressions Conditional Statements, Loops Exception Handling Subprogram definition and activation Simple and Recursive Subprogram Subprogram Environment
Java byte code verification
Java byte code verification SOS Master Science Informatique U. Rennes 1 Thomas Jensen SOS Java byte code verification 1 / 26 Java security architecture Java: programming applications with code from different
Midterm 2. CMSC 430 Introduction to Compilers Fall Instructions Total 100. Name: November 19, 2014
Name: Midterm 2 CMSC 430 Introduction to Compilers Fall 2014 November 19, 2014 Instructions This exam contains 10 pages, including this one. Make sure you have all the pages. Write your name on the top
CS152: Programming Languages. Lecture 11 STLC Extensions and Related Topics. Dan Grossman Spring 2011
CS152: Programming Languages Lecture 11 STLC Extensions and Related Topics Dan Grossman Spring 2011 Review e ::= λx. e x e e c v ::= λx. e c τ ::= int τ τ Γ ::= Γ, x : τ (λx. e) v e[v/x] e 1 e 1 e 1 e
JUnit Testing Framework Architecture
JUnit Testing Framework Architecture Unit under test (usually a class or a small number of classes) Test environment (fixture) Program state (e.g., some collection of variables/objects that will be used
Functional Programming. Pure Functional Programming
Functional Programming Pure Functional Programming Computation is largely performed by applying functions to values. The value of an expression depends only on the values of its sub-expressions (if any).
Module 27 Switch-case statements and Run-time storage management
Module 27 Switch-case statements and Run-time storage management In this module we will discuss the pending constructs in generating three-address code namely switch-case statements. We will also discuss
Operational Semantics. One-Slide Summary. Lecture Outline
Operational Semantics #1 One-Slide Summary Operational semantics are a precise way of specifying how to evaluate a program. A formal semantics tells you what each expression means. Meaning depends on context:
Assembly Language: Function Calls" Goals of this Lecture"
Assembly Language: Function Calls" 1 Goals of this Lecture" Help you learn:" Function call problems:" Calling and returning" Passing parameters" Storing local variables" Handling registers without interference"
Introduce C# as Object Oriented programming language. Explain, tokens,
Module 2 98 Assignment 1 Introduce C# as Object Oriented programming language. Explain, tokens, lexicals and control flow constructs. 99 The C# Family Tree C Platform Independence C++ Object Orientation
Research Collection. Verifying spec# delegates. Master Thesis. ETH Library. Author(s): Gantner, Samuele. Publication Date: 2008
Research Collection Master Thesis Verifying spec# delegates Author(s): Gantner, Samuele Publication Date: 2008 Permanent Link: https://doi.org/10.3929/ethz-a-005677935 Rights / License: In Copyright -
Types. Type checking. Why Do We Need Type Systems? Types and Operations. What is a type? Consensus
Types Type checking What is a type? The notion varies from language to language Consensus A set of values A set of operations on those values Classes are one instantiation of the modern notion of type
Assembly Language: Function Calls" Goals of this Lecture"
Assembly Language: Function Calls" 1 Goals of this Lecture" Help you learn:" Function call problems:" Calling and urning" Passing parameters" Storing local variables" Handling registers without interference"
Runtime Checking for Program Verification Systems
Runtime Checking for Program Verification Systems Karen Zee, Viktor Kuncak, and Martin Rinard MIT CSAIL Tuesday, March 13, 2007 Workshop on Runtime Verification 1 Background Jahob program verification
Softwaretechnik. Lecture 03: Types and Type Soundness. Peter Thiemann. University of Freiburg, Germany SS 2008
Softwaretechnik Lecture 03: Types and Type Soundness Peter Thiemann University of Freiburg, Germany SS 2008 Peter Thiemann (Univ. Freiburg) Softwaretechnik SWT 1 / 35 Table of Contents Types and Type correctness
2 rd class Department of Programming. OOP with Java Programming
1. Structured Programming and Object-Oriented Programming During the 1970s and into the 80s, the primary software engineering methodology was structured programming. The structured programming approach
Copyright 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 16
1 Copyright 2012, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 16 Towards JVM Dynamic Languages Toolchain Insert Picture Here Attila
Introduction to Programming Using Java (98-388)
Introduction to Programming Using Java (98-388) Understand Java fundamentals Describe the use of main in a Java application Signature of main, why it is static; how to consume an instance of your own class;
Software Security: Vulnerability Analysis
Computer Security Course. Software Security: Vulnerability Analysis Program Verification Program Verification How to prove a program free of buffer overflows? Precondition Postcondition Loop invariants
Boolean expressions. Elements of Programming Languages. Conditionals. What use is this?
Boolean expressions Elements of Programming Languages Lecture 3: Booleans, conditionals, and types James Cheney So far we ve considered only a trivial arithmetic language L Arith Let s extend L Arith with
Testing, Debugging, and Verification
Testing, Debugging, and Verification Formal Specification, Part II Srinivas Pinisetty 23 November 2017 Introduction Today: Introduction to Dafny: An imperative language with integrated support for formal
Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Lecture 13. Notation. The rules. Evaluation Rules So Far
Lecture Outline Operational Semantics of Cool Lecture 13 COOL operational semantics Motivation Notation The rules Prof. Aiken CS 143 Lecture 13 1 Prof. Aiken CS 143 Lecture 13 2 Motivation We must specify
A Practical Approach to Programming With Assertions
A Practical Approach to Programming With Assertions Ken Bell Christian-Albrechts Universität Kiel Department of Computer Science and Applied Mathematics Real-Time Systems and Embedded Systems Group July
Last name:... First name:... Department (if not D-INFK):...
Concepts of Object-Oriented Programming AS 2017 Concepts of Object-Oriented Programming Midterm Examination 10.11.2017 Prof. Dr. Peter Müller Last name:................................. First name:.................................
Programming II (CS300)
1 Programming II (CS300) Chapter 03: Creating Classes MOUNA KACEM mouna@cs.wisc.edu Spring 2019 Creating Classes 2 Constructors and Object Initialization Static versus non-static fields/methods Encapsulation
Semantic Analysis. Outline. The role of semantic analysis in a compiler. Scope. Types. Where we are. The Compiler Front-End
Outline Semantic Analysis The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors
Practical VM exploiting based on CACAO
Just in Time compilers - breaking a VM Practical VM exploiting based on CACAO Roland Lezuo, Peter Molnar Just in Time compilers - breaking a VM p. Who are we? We are (were) CS students at Vienna University
Verification Condition Generation
Verification Condition Generation Jorge Sousa Pinto Departamento de Informática / Universidade do Minho jsp@di.uminho.pt www.di.uminho.pt/~jsp Outline (1) - From Hoare Logic to VCGen algorithms: an architecture
The Java Modeling Language (Part 1)
The Java Modeling Language (Part 1) Wolfgang Schreiner Wolfgang.Schreiner@risc.jku.at Research Institute for Symbolic Computation (RISC) Johannes Kepler University, Linz, Austria http://www.risc.jku.at
UNIT 3 ARRAYS, RECURSION, AND COMPLEXITY CHAPTER 11 CLASSES CONTINUED
UNIT 3 ARRAYS, RECURSION, AND COMPLEXITY CHAPTER 11 CLASSES CONTINUED EXERCISE 11.1 1. static public final int DEFAULT_NUM_SCORES = 3; 2. Java allocates a separate set of memory cells in each instance
Practical Reasoning About Invocations and Implementations of Pure Methods
Practical Reasoning About Invocations and Implementations of Pure Methods Ádám Darvas 1 and K. Rustan M. Leino 2 1 ETH Zurich, Switzerland adam.darvas@inf.ethz.ch 2 Microsoft Research, Redmond, WA, USA
Programming II (CS300)
1 Programming II (CS300) Chapter 03: Creating Classes MOUNA KACEM mouna@cs.wisc.edu Spring 2018 Creating Classes 2 Constructors and Object Initialization Static versus non-static fields/methods Encapsulation
Advanced JML. and more tips and pitfalls. David Cok, Joe Kiniry, and Erik Poll
Advanced JML and more tips and pitfalls David Cok, Joe Kiniry, and Erik Poll Eastman Kodak Company, University College Dublin, and Radboud University Nijmegen David Cok, Joe Kiniry & Erik Poll - ESC/Java2
Java Modelling Language (JML) References
Java Modelling Language (JML) References G. T. Leavens and Y. Cheon. Design by Contract with JML, August 2005. L. Burdy, Y. Cheon, D. Cok, M. Ernst, J. Kiniry, G. T. Leavens, K. R. M. Leino, and E. Poll.
Today. Instance Method Dispatch. Instance Method Dispatch. Instance Method Dispatch 11/29/11. today. last time
CS2110 Fall 2011 Lecture 25 Java program last time Java compiler Java bytecode (.class files) Compile for platform with JIT Interpret with JVM Under the Hood: The Java Virtual Machine, Part II 1 run native
Compilation 2012 Code Generation
Compilation 2012 Jan Midtgaard Michael I. Schwartzbach Aarhus University Phases Computing resources, such as: layout of data structures offsets register allocation Generating an internal representation
CSC 4181 Handout : JVM
CSC 4181 Handout : JVM Note: This handout provides you with the basic information about JVM. Although we tried to be accurate about the description, there may be errors. Feel free to check your compiler
JAM 16: The Instruction Set & Sample Programs
JAM 16: The Instruction Set & Sample Programs Copyright Peter M. Kogge CSE Dept. Univ. of Notre Dame Jan. 8, 1999, modified 4/4/01 Revised to 16 bits: Dec. 5, 2007 JAM 16: 1 Java Terms Java: A simple,
Lecture Outline. COOL operational semantics. Operational Semantics of Cool. Motivation. Notation. The rules. Evaluation Rules So Far.
Lecture Outline Operational Semantics of Cool COOL operational semantics Motivation Adapted from Lectures by Profs. Alex Aiken and George Necula (UCB) Notation The rules CS781(Prasad) L24CG 1 CS781(Prasad)
Operational Semantics of Cool
Operational Semantics of Cool Key Concepts semantics: the meaning of a program, what does program do? how the code is executed? operational semantics: high level code generation steps of calculating values
Mnemonics Type-Safe Bytecode Generation in Scala
Mnemonics Type-Safe Bytecode Generation in Scala Johannes Rudolph CleverSoft GmbH, Munich Peter Thiemann Albert-Ludwigs-Universität Freiburg, Germany Scala Days 2010, Lausanne, 15.04.2010 Existing bytecode
The role of semantic analysis in a compiler
Semantic Analysis Outline The role of semantic analysis in a compiler A laundry list of tasks Scope Static vs. Dynamic scoping Implementation: symbol tables Types Static analyses that detect type errors
Assembly Language: Function Calls
Assembly Language: Function Calls 1 Goals of this Lecture Help you learn: Function call problems: Calling and returning Passing parameters Storing local variables Handling registers without interference
An Experimental Evaluation of Deliberate Unsoundness in a Static Program Analyzer
An Experimental Evaluation of Deliberate Unsoundness in a Static Program Analyzer Maria Christakis, Peter Müller, and Valentin Wüstholz Department of Computer Science ETH Zurich, Switzerland {maria.christakis,
6.170 Lecture 7 Abstract Data Types MIT EECS
6.170 Lecture 7 Abstract Data Types MIT EECS Outline 1. What is an abstract data type (ADT)? 2. How to specify an ADT immutable mutable 3. The ADT methodology 2 What is an ADT? Procedural abstraction Abstracts
Inspector Methods for State Abstraction
Vol. 6, No. 5, Special Issue: Workshop on FTfJP, ECOOP 2006, Juni 2007 Inspector Methods for State Abstraction Bart Jacobs, Frank Piessens, Katholieke Universiteit Leuven, Belgium Most classes in an object-oriented
Assertions, pre/postconditions
Programming as a contract Assertions, pre/postconditions Assertions: Section 4.2 in Savitch (p. 239) Specifying what each method does q Specify it in a comment before method's header Precondition q What