MoreVMs'18: Sulong, and Thanks for All the Fish

Talk at the Workshop on Modern Language Runtimes, Ecosystems, and VMs 2018 (see https://2018.programming-conference.org/track/MoreVMs-2018)

Transcript

1. Sulong, and Thanks for All the Fish Manuel Rigger, Jacob Kreindl, Hanspeter Mössenböck Roland Schatz, Christian Häubl MoreVMs 2018, April 9, 2018
2. Project Sulong 2 Execute LLVM-based languages on the GraalVM
3. 3 https://twitter.com/LucasWerkmeistr/status/780829630890672128 So Long, and Thanks for All the Fish: fourth book of the Hitchhiker's Guide to the Galaxy by Douglas Adams
4. Sulong as Part of GraalVM 4 Java Virtual Machine Graal Compiler Truffle Framework https://github.com/graalvm/ TruffleRuby Graal.js Graal.python FastR (Würthinger et al. 2016)
5. Sulong as Part of GraalVM 4 Java Virtual Machine Graal Compiler Truffle Framework https://github.com/graalvm/ TruffleRuby Graal.js Graal.python FastR Optimization Boundary (Würthinger et al. 2016)
6. Sulong as Part of GraalVM 5 Java Virtual Machine Graal Compiler Truffle Framework https://github.com/graalvm/ TruffleRuby Graal.js Graal.python FastR Optimization Boundary Java Native Interface (Würthinger et al. 2016)
7. Sulong as Part of GraalVM 6 Java Virtual Machine Graal Compiler Truffle Framework https://github.com/graalvm/ TruffleRuby Graal.js Graal.python FastR Optimization Boundary LLVM IR Interpreter LLVM IR Clang Flang (Würthinger et al. 2016)
8. Sulong as Part of GraalVM 7 Java Virtual Machine Graal Compiler Truffle Framework https://github.com/graalvm/ LLVM IR Interpreter LLVM IR Clang Flang
9. Structure • LLVM IR interpreter • Data representation • Discussion: Undefined Behavior in C 8
10. LLVM IR Interpreter 9
11. Example Program 10 void processRequests () { int i = 0; do { processPacket (); i ++; } while (i < 10000) ; } C
12. Example Program 10 void processRequests () { int i = 0; do { processPacket (); i ++; } while (i < 10000) ; } define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Clang C
13. 11 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Implementation of Operations
14. 11 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Executable Abstract Syntax Tree Implementation of Operations write %2 add read %i 1
15. write %2 add read %i 1 Implementation of Operations 12 Executable Abstract Syntax Tree class LLVMI32AddNode extends LLVMExpressionNode { protected int executeI32(int left, int right) { return left + right; } }
16. 13 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Implementation of Basic Blocks
17. 13 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Executable Abstract Syntax Tree Implementation of Basic Blocks Block1
18. Implementation of Control Flow Support 14 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Unstructured control-flow is not representable as an AST interpreter
19. Implementation of Control Flow Support 15 define void @processRequests () #0 { ; ( basic block 0) br label %1 ; <label >:1 ( basic block 1) %i = phi i32 [ 0, %0 ], [ %2 , %1 ] call void @processPacket () %2 = add nsw i32 %i, 1 %3 = icmp slt i32 %2 , 10000 br i1 %3 , label %1 , label %4 ; <label >:4 ( basic block 2) ret void } LLVM IR Block0 Block1 Block2 Basic Block Dispatch Node 1 2 -1 1 Bytecode-like interpreter
20. Compilation • For frequently executed functions • Partial evaluation: inline through the interpreter (recursively) 16 Block0 Block1 Block2 Basic Block Dispatch Node 1 2 -1 1
21. Block0 Block1 Block2 Basic Block Dispatch Node 1 2 -1 1 Compiler 17 int blockIndex = 0; block0: blockIndex = 1 %i.0 = 0 block1: while (true): processPacket() %2 = %i.0 + 1 %3 = %2 < 10000 if %3: blockIndex = 1 %i.0 = %2 continue; else: blockIndex = 2 block2: blockIndex = -1 return Partially evaluated interpreter
22. Block0 Block1 Block2 Basic Block Dispatch Node 1 2 -1 1 Compiler 17 int blockIndex = 0; block0: blockIndex = 1 %i.0 = 0 block1: while (true): processPacket() %2 = %i.0 + 1 %3 = %2 < 10000 if %3: blockIndex = 1 %i.0 = %2 continue; else: blockIndex = 2 block2: blockIndex = -1 return Partially evaluated interpreter Graal further optimizes the partially evaluated interpreter
23. Data Representations 18
24. How to represent allocations 19 int *arr = malloc(sizeof(int) * 4); %1 = call i8* @malloc(i64 16) %2 = bitcast i8* %1 to i32*
25. Tradeoffs Memory Safety Native Interoperability 20 int *arr = malloc(4 * sizeof(int)); arr[5] = … process(object) program.c lib.so Shared libraries without source code
26. How to represent allocations 21 LLVM IR Interpreter Native Strategy LLVM IR Interpreter Safe Strategy Native Strategy
27. How to represent allocations 22 + Native interoperability - No memory safety LLVM IR Interpreter Safe Strategy Native Strategy (Rigger et al. 2016)
28. Native Sulong 23 Native Strategy %1 = call i8* @malloc(i64 16) %2 = bitcast i8* %1 to i32* unsafe.allocateMemory(16); sun.misc.Unsafe https://github.com/graalvm/sulong 0x8892042312 (Rigger et al. 2016)
29. process(object) program.c lib.so Native Sulong: Native Interoperability 24 0x8892042312 Native Strategy (Rigger et al. 2016)
30. Native Sulong: Memory Safety 25 int *arr = malloc(4 * sizeof(int)) arr[5] = … Native Strategy (Rigger et al. 2018)
31. Native Sulong: Memory Safety 25 int *arr = malloc(4 * sizeof(int)) arr[5] = … Native Strategy (Rigger et al. 2018)
32. How to represent allocations 26 + Memory safety - No interoperability LLVM IR Interpreter Safe Strategy Native Strategy (Rigger et al. 2018)
33. Safe Sulong 27 Safe Strategy %1 = call i8* @malloc(i64 16) %2 = bitcast i8* %1 to i32* Address offset = 0 data UntypedAllocation size=16 (Rigger et al. 2018)
34. Safe Sulong 28 %1 = call i8* @malloc(i64 16) %2 = bitcast i8* %1 to i32* Address offset = 0 data I32Array contents {0, 0, 0, 0} Safe Strategy Address offset = 0 data UntypedAllocation size=16 (Rigger et al. 2018)
35. Prevent Out-Of-Bounds Accesses 29 int *arr = malloc(4 * sizeof(int)) arr[5] = … Safe Strategy Address offset = 5 data I32Array contents {0, 0, 0, 0} (Rigger et al. 2018)
36. Prevent Out-Of-Bounds Accesses contents[5]  ArrayIndexOutOfBoundsException 29 int *arr = malloc(4 * sizeof(int)) arr[5] = … Safe Strategy Address offset = 5 data I32Array contents {0, 0, 0, 0} (Rigger et al. 2018)
37. Address offset = 0 data I32Array contents {0, 0, 0, 0} process(object) program.c lib.so Native Interoperability 30 Safe Strategy (Rigger et al. 2018)
38. Address offset = 0 data I32Array contents {0, 0, 0, 0} process(object) program.c lib.so Native Interoperability 30 Safe Strategy (Rigger et al. 2018)
39. Native Interoperability 31 Ongoing work: safe execution of machine code on Safe Sulong Safe Strategy
40. Native Interoperability 32 LLVM IR Interpreter LLVM IR lib.so Truffle Graal JVM x86 Interpreter x86 interpreter Safe Strategy (Lockhart et al. 2018)
41. Native Interoperability 33 LLVM IR Interpreter LLVM IR LLVM IR Lifter lib.so Truffle Graal JVM Lifting Machine code to LLVM IR Safe Strategy
42. How to represent allocations 34 Combine advantages LLVM IR Interpreter Safe Strategy Native Strategy Managed Strategy
43. Semantic Holes in the C Standard 35
44. write %2 add read %i 1 Simple Operations 36 Executable Abstract Syntax Tree The result of the binary operator is the sum of the operands. C11 standard
45. write %2 add read %i 1 Simple Operations 36 Executable Abstract Syntax Tree class LLVMI32AddNode extends LLVMExpressionNode { @Specialization protected int executeI32(int left, int right) { return left + right; } } The result of the binary operator is the sum of the operands. C11 standard
46. Defined Behavior in C 37 Implementing the semantics described in the standard is relatively straightforward C11
47. Undefined Behavior 38 UB: … ranges from ignoring the situation completely with unpredictable results [to more sane behavior] int a = 1, b = INT_MAX; int val = a + b; printf("%d\n", val); UB
48. What to do about UB? 39 Safe Strategy Increasingly powerful optimizations exploit UB
49. What to do about UB? 39 Terminate the program Safe Strategy Increasingly powerful optimizations exploit UB
50. What to do about UB? 40 write %2 add read %i 1 Executable Abstract Syntax Tree class LLVMI32AddNode extends LLVMExpressionNode { @Specialization protected int executeI32(int left, int right) { return Math.addExact(left, right); } } Safe Strategy
51. Problem 41 Programmers often rely on Undefined Behavior being defined C11
52. Problem 41 Programmers often rely on Undefined Behavior being defined C11
53. What about the users? 42 6/9 of SPEC CINT 2006 benchmarks contain undefined integer operations alone (Dietz et al. 2018)
54. For the kernel, we already really ignore some of the more idiotic C standard rules that introduce pointless undefined behavior: things like the strict aliasing rules are just insane, and the "overflow is u[nd]efined" is bad too. So we use -fno-strict-aliasing -fno-strict-overflow -fno-delete-null-pointer-checks to basically say "those optimizations are fundamentally stupid and wrong, and only encourage compilers to generate random code that doesn't actually match the source code". UB in the Linux Kernel 43 Linus 2017
55. What to do about UB? 44 Terminate the program Continue execution Safe Strategy Many programs that we want to execute rely on UB having semantics
56. What to do about UB? 45 write %2 add read %i 1 Executable Abstract Syntax Tree class LLVMI32AddNode extends LLVMExpressionNode { @Specialization protected int executeI32(int left, int right) { return left + right; } } Wraparound semantics for signed integer overflow Safe Strategy (Rigger et al. 2017)
57. 46 Is it always that simple?
58. Undefined Behavior 47 void* memmove(void *dest , void const *src , size_t n ) { char *dp = dest; char const *sp = src; if (dp < sp) { while (n-- > 0) *dp++ = *sp++; } else { dp += n; sp += n; while (n-- > 0) *--dp = *--sp ; } return dest; } What’s the Undefined Behavior?
59. Undefined Behavior 48 void* memmove(void *dest , void const *src , size_t n ) { char *dp = dest; char const *sp = src; if (dp < sp) { while (n-- > 0) *dp++ = *sp++; } else { dp += n; sp += n; while (n-- > 0) *--dp = *--sp ; } return dest; } UB Using < to compare pointers to two different objects is UB!
60. Does code rely on it? 49 Response % of Respondants Yes 33% Yes, but it shouldn’t 12% No, but there might well be 29% No, that would be crazy 16% Don’t know 8% Q25 Can one do relational comparison (with <, >, <=, or >=) of two pointers to separately allocated objects (of compatible object types)? (Memarian et al. 2016)
61. Integer Representation: Native Sulong 50 integer_rep(a) = a Native Strategy 0x8892042312
62. Integer Representation: Safe Sulong 51 integer_rep(a) = a.offset satisfies the standard… but what about pointers to different objects? Safe Strategy Address offset = 0 data I32Array contents {0, 0, 0, 0}
63. Integer Representation: Safe Sulong 52 Breaks antisymmetry as different objects might have the same hash code Safe Strategy integer_rep(a) = (long) System.identityHashCode(a.pointee) << 32 | offset; Address offset = 0 data I32Array contents {0, 0, 0, 0}
64. Address offset = 0 data I32Array contents {0, 0, 0, 0} id = 1000 id = 1001 Integer Representation: Safe Sulong 53 integer_rep(a) = a.pointee.id Assign distinct IDs? Safe Strategy
65. What to do about Undefined Behavior? 54 ~200 other instances of undefined behavior in addition to unspecified and implementation-defined behavior UB Unspecified- behavior Implementation- defined Behavior Locale-specific Behavior Defined Behavior
66. What to do about Undefined Behavior? 55 Terminate the program Continue execution Discussion: How should Undefined Behavior be dealt with and who should deal with it?
67. Is the C standard still up-to-date? 56 What should happen is a matter for implementations; it is impossible, in the language specification, to anticipate the details of the implementation scenario. – Stephen Kell (Kell 2017)
68. Is the C standard still up-to-date? 57 I don’t even want to entertain the idea of a big family of Friendly C dialects, each making some niche audience happy– that is not really an improvement over our current situation. – John Regehr
69. Summary 58 @RiggerManuel
70. Bibliography • D. Lockhart, B. Ilbeyi and C. Batten, "Pydgin: generating fast instruction set simulators from simple architecture descriptions with meta-tracing JIT compilers," 2015 IEEE International Symposium on Performance Analysis of Systems and Software (ISPASS), Philadelphia, PA, 2015, pp. 256-267. https://doi.org/10.1109/ISPASS.2015.7095811 • Kayvan Memarian, Justus Matthiesen, James Lingard, Kyndylan Nienhuis, David Chisnall, Robert N. M. Watson, and Peter Sewell. 2016. Into the depths of C: elaborating the de facto standards. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI '16). ACM, New York, NY, USA, 1-15. DOI: https://doi.org/10.1145/2908080.2908081 • Manuel Rigger, Roland Schatz, Matthias Grimmer, and Hanspeter Mössenböck. 2017. Lenient Execution of C on a Java Virtual Machine: or: How I Learned to Stop Worrying and Run the Code. In Proceedings of the 14th International Conference on Managed Languages and Runtimes (ManLang 2017). ACM, New York, NY, USA, 35-47. DOI: https://doi.org/10.1145/3132190.3132204 • Manuel Rigger, Matthias Grimmer, Christian Wimmer, Thomas Würthinger, and Hanspeter Mössenböck. 2016. Bringing low-level languages to the JVM: efficient execution of LLVM IR on Truffle. In Proceedings of the 8th International Workshop on Virtual Machines and Intermediate Languages (VMIL 2016). ACM, New York, NY, USA, 6-15. DOI: https://doi.org/10.1145/2998415.2998416 • Manuel Rigger, Roland Schatz, René Mayrhofer, Matthias Grimmer, and Hanspeter Mössenböck. 2018. Sulong, and Thanks for All the Bugs: Finding Errors in C Programs by Abstracting from the Native Execution Model. In Proceedings of the Twenty-Third International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS '18). ACM, New York, NY, USA, 377-391. DOI: https://doi.org/10.1145/3173162.3173174 • Stephen Kell. 2017. Some were meant for C: the endurance of an unmanageable language. In Proceedings of the 2017 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (Onward! 2017). ACM, New York, NY, USA, 229-245. DOI: https://doi.org/10.1145/3133850.3133867 • Thomas Würthinger, Christian Wimmer, Andreas Wöß, Lukas Stadler, Gilles Duboscq, Christian Humer, Gregor Richards, Doug Simon, and Mario Wolczko. 2013. One VM to rule them all. In Proceedings of the 2013 ACM international symposium on New ideas, new paradigms, and reflections on programming & software (Onward! 2013). ACM, New York, NY, USA, 187-204. DOI=http://dx.doi.org/10.1145/2509578.2509581 • Will Dietz, Peng Li, John Regehr, and Vikram Adve. 2012. Understanding integer overflow in C/C++. In Proceedings of the 34th International Conference on Software Engineering (ICSE '12). IEEE Press, Piscataway, NJ, USA, 760-770. 59