Changeset b680198
- Timestamp:
- Jun 23, 2021, 2:06:12 PM (3 years ago)
- Branches:
- ADT, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum
- Children:
- 68b52b0
- Parents:
- 6ba6846 (diff), 929d925 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the(diff)
links above to see all the changes relative to each parent. - Location:
- doc/theses/andrew_beach_MMath
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/andrew_beach_MMath/existing.tex
r6ba6846 rb680198 1 \chapter{\CFA Existing Features}1 \chapter{\CFA{} Existing Features} 2 2 \label{c:existing} 3 3 … … 9 9 existing C code-base allowing programmers to learn \CFA on an as-needed basis. 10 10 11 Only those \CFA features pertaining to this thesis are discussed. Many of the12 \CFA syntactic and semantic features used in the thesis should be fairly 13 obvious to the reader.11 Only those \CFA features pertaining to this thesis are discussed. 12 Also, only new features of \CFA will be discussed, a familiarity with 13 C or C-like languages is assumed. 14 14 15 15 \section{Overloading and \lstinline{extern}} … … 29 29 // name mangling on by default 30 30 int i; // _X1ii_1 31 @extern "C"@{ // disables name mangling31 extern "C" { // disables name mangling 32 32 int j; // j 33 @extern "Cforall"@{ // enables name mangling33 extern "Cforall" { // enables name mangling 34 34 int k; // _X1ki_1 35 35 } … … 47 47 Reference-types are written the same way as a pointer-type but each 48 48 asterisk (@*@) is replaced with a ampersand (@&@); 49 this includes cv-qualifiers and multiple levels of reference, \eg: 50 49 this includes cv-qualifiers and multiple levels of reference. 50 51 Generally, references act like pointers with an implicate dereferencing 52 operation added to each use of the variable. 53 These automatic dereferences may be disabled with the address-of operator 54 (@&@). 55 56 % Check to see if these are generating errors. 51 57 \begin{minipage}{0,5\textwidth} 52 58 With references: … … 56 62 int && rri = ri; 57 63 rri = 3; 58 &ri = &j; // reference assignment64 &ri = &j; 59 65 ri = 5; 60 66 \end{cfa} … … 67 73 int ** ppi = π 68 74 **ppi = 3; 69 pi = &j; // pointer assignment75 pi = &j; 70 76 *pi = 5; 71 77 \end{cfa} 72 78 \end{minipage} 73 79 74 References are intended for cases where you would want touse pointers but would80 References are intended to be used when you would use pointers but would 75 81 be dereferencing them (almost) every usage. 76 In most cases a reference can just be thought of as a pointer that 77 automatically puts a dereference in front of each of its uses (per-level of 78 reference). 79 The address-of operator (@&@) acts as an escape and removes one of the 80 automatic dereference operations. 81 Mutable references may be assigned by converting them to a pointer 82 with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above. 82 Mutable references may be assigned to by converting them to a pointer 83 with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above 83 84 84 85 \section{Operators} 85 86 86 In general, operator names in \CFA are constructed by bracketing an operator 87 token with @?@, which indicates the position of the arguments. For example, 87 \CFA implements operator overloading by providing special names. 88 Operator uses are translated into function calls using these names. 89 These names are created by taking the operator symbols and joining them with 90 @?@s to show where the arguments go. 91 For example, 88 92 infixed multiplication is @?*?@ while prefix dereference is @*?@. 89 93 This syntax make it easy to tell the difference between prefix operations 90 94 (such as @++?@) and post-fix operations (@?++@). 91 95 92 An operator name may describe any function signature (it is just a name) but 93 only certain signatures may be called in operator form. 94 \begin{cfa} 95 int ?+?( int i, int j, int k ) { return i + j + k; } 96 { 97 sout | ?+?( 3, 4, 5 ); // no infix form 98 } 99 \end{cfa} 100 Some ``near-misses" for unary/binary operator prototypes generate warnings. 96 \begin{cfa} 97 point ?+?(point a, point b) { return point{a.x + b.x, a.y + b.y}; } 98 bool ?==?(point a, point b) { return a.x == b.x && a.y == b.y; } 99 { 100 assert(point{1, 2} + point{3, 4} == point{4, 6}); 101 } 102 \end{cfa} 103 Note that these special names are not limited to just being used for these 104 operator functions, and may be used name other declarations. 105 Some ``near misses", that will not match an operator form but looks like 106 it may have been supposed to, will generate wantings but otherwise they are 107 left alone. 108 109 %\subsection{Constructors and Destructors} 101 110 102 111 Both constructors and destructors are operators, which means they are 103 112 functions with special operator names rather than type names in \Cpp. The 104 special operator names may be used to call the functions explicitly (not 105 allowed in \Cpp for constructors). 106 107 The special name for a constructor is @?{}@, where the name @{}@ comes from the 108 initialization syntax in C, \eg @Structure s = {...}@. 109 % That initialization syntax is also the operator form. 110 \CFA generates a constructor call each time a variable is declared, 111 passing the initialization arguments to the constructor. 112 \begin{cfa} 113 struct Structure { ... }; 114 void ?{}(Structure & this) { ... } 115 { 116 Structure a; 117 Structure b = {}; 118 } 119 void ?{}(Structure & this, char first, int num) { ... } 120 { 121 Structure c = {'a', 2}; 122 } 123 \end{cfa} 124 Both @a@ and @b@ are initialized with the first constructor, 125 while @c@ is initialized with the second. 126 Currently, there is no general way to skip initialization. 113 special operator names may be used to call the functions explicitly. 114 % Placement new means that this is actually equivant to C++. 115 116 The special name for a constructor is @?{}@, which comes from the 117 initialization syntax in C, \eg @Example e = { ... }@. 118 \CFA will generate a constructor call each time a variable is declared, 119 passing the initialization arguments to the constructort. 120 \begin{cfa} 121 struct Example { ... }; 122 void ?{}(Example & this) { ... } 123 { 124 Example a; 125 Example b = {}; 126 } 127 void ?{}(Example & this, char first, int num) { ... } 128 { 129 Example c = {'a', 2}; 130 } 131 \end{cfa} 132 Both @a@ and @b@ will be initalized with the first constructor, 133 while @c@ will be initalized with the second. 134 Currently, there is no general way to skip initialation. 127 135 128 136 % I don't like the \^{} symbol but $^\wedge$ isn't better. 129 Similarly, destructors use the special name @^?{}@ (the @^@ has no special 130 meaning). Normally, they are implicitly called on a variable when it goes out 131 of scope but they can be called explicitly as well. 132 \begin{cfa} 133 void ^?{}(Structure & this) { ... } 134 { 135 Structure d; 137 Similarly destructors use the special name @^?{}@ (the @^@ has no special 138 meaning). 139 These are a normally called implicitly called on a variable when it goes out 140 of scope. They can be called explicitly as well. 141 \begin{cfa} 142 void ^?{}(Example & this) { ... } 143 { 144 Example d; 136 145 } // <- implicit destructor call 137 146 \end{cfa} 138 147 139 Whenever a type is defined, \CFA createsa default zero-argument148 Whenever a type is defined, \CFA will create a default zero-argument 140 149 constructor, a copy constructor, a series of argument-per-field constructors 141 150 and a destructor. All user constructors are defined after this. … … 198 207 void do_once(double y) { ... } 199 208 int quadruple(int x) { 200 void do_once(int y) { y = y * 2; } // replace global do_once 201 do_twice(x); // use local do_once 202 do_twice(x + 1.5); // use global do_once 209 void do_once(int & y) { y = y * 2; } 210 do_twice(x); 203 211 return x; 204 212 } 205 213 \end{cfa} 206 214 Specifically, the complier deduces that @do_twice@'s T is an integer from the 207 argument @x@. It then looks for the most \emph{specific}definition matching the215 argument @x@. It then looks for the most specific definition matching the 208 216 assertion, which is the nested integral @do_once@ defined within the 209 217 function. The matched assertion function is then passed as a function pointer 210 to @do_twice@ and called within it. The global definition of @do_once@ is used 211 for the second call because the float-point argument is a better match. 218 to @do_twice@ and called within it. 219 The global definition of @do_once@ is ignored, however if quadruple took a 220 @double@ argument then the global definition would be used instead as it 221 would be a better match. 222 % Aaron's thesis might be a good reference here. 212 223 213 224 To avoid typing long lists of assertions, constraints can be collect into … … 279 290 Each coroutine has a @main@ function, which takes a reference to a coroutine 280 291 object and returns @void@. 281 \begin{cfa}[numbers=left] 292 %[numbers=left] Why numbers on this one? 293 \begin{cfa} 282 294 void main(CountUp & this) { 283 295 for (unsigned int next = 0 ; true ; ++next) { -
doc/theses/andrew_beach_MMath/features.tex
r6ba6846 rb680198 2 2 \label{c:features} 3 3 4 This chapter covers the design and user interface of the \CFA 5 EHM, % or exception system. 4 This chapter covers the design and user interface of the \CFA EHM 6 5 and begins with a general overview of EHMs. It is not a strict 7 6 definition of all EHMs nor an exhaustive list of all possible features. 8 However it does cover the most common structures and features found in them. 9 7 However it does cover the most common structure and features found in them. 8 9 \section{Overview of EHMs} 10 10 % We should cover what is an exception handling mechanism and what is an 11 11 % exception before this. Probably in the introduction. Some of this could 12 12 % move there. 13 \s ection{Raise / Handle}13 \subsection{Raise / Handle} 14 14 An exception operation has two main parts: raise and handle. 15 These terms are sometimes alsoknown as throw and catch but this work uses15 These terms are sometimes known as throw and catch but this work uses 16 16 throw/catch as a particular kind of raise/handle. 17 17 These are the two parts that the user writes and may … … 24 24 25 25 Some well known examples include the @throw@ statements of \Cpp and Java and 26 the \code{Python}{raise} statement from Python. Araise may27 p erform some other work (such as memory management) but for the26 the \code{Python}{raise} statement from Python. In real systems a raise may 27 preform some other work (such as memory management) but for the 28 28 purposes of this overview that can be ignored. 29 29 … … 33 33 34 34 A handler has three common features: the previously mentioned user code, a 35 region of code they guard ,and an exception label/condition that matches35 region of code they guard and an exception label/condition that matches 36 36 certain exceptions. 37 37 Only raises inside the guarded region and raising exceptions that match the 38 38 label can be handled by a given handler. 39 Different EHMs have different rules to pick a handler,40 if multiple handlers could be used, such as ``best match" or ``first found".39 If multiple handlers could can handle an exception, 40 EHMs will define a rule to pick one, such as ``best match" or ``first found". 41 41 42 42 The @try@ statements of \Cpp, Java and Python are common examples. All three … … 44 44 region. 45 45 46 \s ection{Propagation}46 \subsection{Propagation} 47 47 After an exception is raised comes what is usually the biggest step for the 48 48 EHM: finding and setting up the handler. The propagation from raise to 49 49 handler can be broken up into three different tasks: searching for a handler, 50 matching against the handler ,and installing the handler.50 matching against the handler and installing the handler. 51 51 52 52 \paragraph{Searching} … … 55 55 thrown as it looks for handlers that have the raise site in their guarded 56 56 region. 57 Th is search includes handlers in the current function, as well as any in callers58 on the stack that have the function call in their guarded region.57 The search includes handlers in the current function, as well as any in 58 callers on the stack that have the function call in their guarded region. 59 59 60 60 \paragraph{Matching} 61 61 Each handler found has to be matched with the raised exception. The exception 62 label defines a condition that is used with the exception to decideif62 label defines a condition that is used with exception and decides if 63 63 there is a match or not. 64 64 65 65 In languages where the first match is used, this step is intertwined with 66 searching : a match check is performed immediately after the search finds66 searching; a match check is preformed immediately after the search finds 67 67 a possible handler. 68 68 69 \ section{Installing}69 \paragraph{Installing} 70 70 After a handler is chosen it must be made ready to run. 71 71 The implementation can vary widely to fit with the rest of the … … 74 74 case when stack unwinding is involved. 75 75 76 If a matching handler is not guarant ied to be found, the EHM needs a76 If a matching handler is not guaranteed to be found, the EHM needs a 77 77 different course of action for the case where no handler matches. 78 78 This situation only occurs with unchecked exceptions as checked exceptions 79 79 (such as in Java) can make the guarantee. 80 This unhandled action can abort the program or install a very general handler.80 This unhandled action is usually very general, such as aborting the program. 81 81 82 82 \paragraph{Hierarchy} 83 83 A common way to organize exceptions is in a hierarchical structure. 84 This organization is often used inobject-orientated languages where the84 This pattern comes from object-orientated languages where the 85 85 exception hierarchy is a natural extension of the object hierarchy. 86 86 … … 90 90 \end{center} 91 91 92 A handler label led with any given exception can handle exceptions of that92 A handler labeled with any given exception can handle exceptions of that 93 93 type or any child type of that exception. The root of the exception hierarchy 94 94 (here \code{C}{exception}) acts as a catch-all, leaf types catch single types … … 104 104 % Could I cite the rational for the Python IO exception rework? 105 105 106 \ paragraph{Completion}107 After the handler has finished the entire exception operation has to complete106 \subsection{Completion} 107 After the handler has finished, the entire exception operation has to complete 108 108 and continue executing somewhere else. This step is usually simple, 109 109 both logically and in its implementation, as the installation of the handler … … 111 111 112 112 The EHM can return control to many different places, 113 the most common are after the handler definition (termination) and after the raise (resumption). 114 115 \paragraph{Communication} 113 the most common are after the handler definition (termination) 114 and after the raise (resumption). 115 116 \subsection{Communication} 116 117 For effective exception handling, additional information is often passed 117 118 from the raise to the handler and back again. 118 119 So far only communication of the exceptions' identity has been covered. 119 A common communication method is putting fields into the exception instance and giving the 120 handler access to them. References in the exception instance can push data back to the raise. 120 A common communication method is putting fields into the exception instance 121 and giving the handler access to them. 122 Passing the exception by reference instead of by value can allow data to be 123 passed in both directions. 121 124 122 125 \section{Virtuals} 123 126 Virtual types and casts are not part of \CFA's EHM nor are they required for 124 127 any EHM. 125 However, one of the best ways to support an exception hierarchy is via a virtual system126 among exceptions and used for exception matching.128 However, it is one of the best ways to support an exception hierarchy 129 is via a virtual hierarchy and dispatch system. 127 130 128 131 Ideally, the virtual system would have been part of \CFA before the work 129 132 on exception handling began, but unfortunately it was not. 130 Therefore, only the features and framework needed for the EHM were133 Hence, only the features and framework needed for the EHM were 131 134 designed and implemented. Other features were considered to ensure that 132 the structure could accommodate other desirable features in the future but they were not133 implemented.134 The rest of this section discusses the implemented subset of the135 virtual -system design.135 the structure could accommodate other desirable features in the future 136 but they were not implemented. 137 The rest of this section will only discuss the implemented subset of the 138 virtual system design. 136 139 137 140 The virtual system supports multiple ``trees" of types. Each tree is … … 143 146 % A type's ancestors are its parent and its parent's ancestors. 144 147 % The root type has no ancestors. 145 % A type's de cedents are its children and its children's decedents.148 % A type's descendants are its children and its children's descendants. 146 149 147 150 Every virtual type also has a list of virtual members. Children inherit … … 150 153 of object-orientated programming, and can be of any type. 151 154 152 \PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$153 155 \CFA still supports virtual methods as a special case of virtual members. 154 156 Function pointers that take a pointer to the virtual type are modified 155 157 with each level of inheritance so that refers to the new type. 156 158 This means an object can always be passed to a function in its virtual table 157 as if it were a method.} 159 as if it were a method. 160 \todo{Clarify (with an example) virtual methods.} 158 161 159 162 Each virtual type has a unique id. … … 161 164 into a virtual table type. Each virtual type has a pointer to a virtual table 162 165 as a hidden field. 163 164 \PAB{God forbid, maybe you need a UML diagram to relate these entities.} 166 \todo{Might need a diagram for virtual structure.} 165 167 166 168 Up until this point the virtual system is similar to ones found in … … 173 175 types can begin to satisfy a trait, stop satisfying a trait or satisfy the same 174 176 trait in a different way at any lexical location in the program. 175 In this sense, they are ``open" as they can change at any time. This capability means it176 is impossible to pick a single set of functions that represent the type's177 implementation across the program.177 In this sense, they are ``open" as they can change at any time. 178 This capability means it is impossible to pick a single set of functions 179 that represent the type's implementation across the program. 178 180 179 181 \CFA side-steps this issue by not having a single virtual table for each 180 182 type. A user can define virtual tables that are filled in at their 181 declaration and given a name. Anywhere that name is visible, even if 183 declaration and given a name. Anywhere that name is visible, even if it is 182 184 defined locally inside a function (although that means it does not have a 183 185 static lifetime), it can be used. … … 186 188 through the object. 187 189 188 \PAB{The above explanation is very good!}189 190 190 While much of the virtual infrastructure is created, it is currently only used 191 191 internally for exception handling. The only user-level feature is the virtual 192 cast 192 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}. 193 193 \label{p:VirtualCast} 194 194 \begin{cfa} 195 195 (virtual TYPE)EXPRESSION 196 196 \end{cfa} 197 which is the same as the \Cpp \code{C++}{dynamic_cast}.198 197 Note, the syntax and semantics matches a C-cast, rather than the function-like 199 198 \Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be … … 218 217 The trait is defined over two types, the exception type and the virtual table 219 218 type. Each exception type should have a single virtual table type. 220 There are no actual assertions in this trait because currentlythe trait system221 cannot express them (adding such assertions would be part of219 There are no actual assertions in this trait because the trait system 220 cannot express them yet (adding such assertions would be part of 222 221 completing the virtual system). The imaginary assertions would probably come 223 222 from a trait defined by the virtual system, and state that the exception type 224 is a virtual type, is a descend ent of @exception_t@ (the base exception type)223 is a virtual type, is a descendant of @exception_t@ (the base exception type) 225 224 and note its virtual table type. 226 225 … … 241 240 }; 242 241 \end{cfa} 243 Both traits ensure a pair of types are an exception type and its virtual table, 242 Both traits ensure a pair of types are an exception type, its virtual table 243 type 244 244 and defines one of the two default handlers. The default handlers are used 245 245 as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}. … … 269 269 \section{Exception Handling} 270 270 \label{s:ExceptionHandling} 271 As stated, \CFA provides two kinds of exception handling: termination and resumption. 271 As stated, 272 \CFA provides two kinds of exception handling: termination and resumption. 272 273 These twin operations are the core of \CFA's exception handling mechanism. 273 This section coversthe general patterns shared by the two operations and274 then go on to cover the details ofeach individual operation.274 This section will cover the general patterns shared by the two operations and 275 then go on to cover the details each individual operation. 275 276 276 277 Both operations follow the same set of steps. 277 Both start with the user p erforming a raise on an exception.278 Both start with the user preforming a raise on an exception. 278 279 Then the exception propagates up the stack. 279 280 If a handler is found the exception is caught and the handler is run. 280 After that control returns to a point specific to the kind of exception.281 If the search fails a default handler is run , and if it returns,control282 continues after the raise. Note, the default handler may further change control flow rather than return.281 After that control continues at a raise-dependent location. 282 If the search fails a default handler is run and, if it returns, then control 283 continues after the raise. 283 284 284 285 This general description covers what the two kinds have in common. 285 Differences include how propagation is p erformed, where exception continues286 Differences include how propagation is preformed, where exception continues 286 287 after an exception is caught and handled and which default handler is run. 287 288 288 289 \subsection{Termination} 289 290 \label{s:Termination} 290 291 291 Termination handling is the familiar kind and used in most programming 292 292 languages with exception handling. … … 313 313 314 314 The throw copies the provided exception into managed memory to ensure 315 the exception is not destroyed whenthe stack is unwound.315 the exception is not destroyed if the stack is unwound. 316 316 It is the user's responsibility to ensure the original exception is cleaned 317 317 up whether the stack is unwound or not. Allocating it on the stack is 318 318 usually sufficient. 319 319 320 Then propagation starts the search. \CFA uses a ``first match" rule so 321 matching is performed with the copied exception as the search continues. 322 It starts from the throwing function and proceeds towards the base of the stack, 320 % How to say propagation starts, its first sub-step is the search. 321 Then propagation starts with the search. \CFA uses a ``first match" rule so 322 matching is preformed with the copied exception as the search continues. 323 It starts from the throwing function and proceeds towards base of the stack, 323 324 from callee to caller. 324 325 At each stack frame, a check is made for resumption handlers defined by the … … 334 335 \end{cfa} 335 336 When viewed on its own, a try statement simply executes the statements 336 in \snake{GUARDED_BLOCK} and when those are finished, the try statement finishes. 337 in \snake{GUARDED_BLOCK} and when those are finished, 338 the try statement finishes. 337 339 338 340 However, while the guarded statements are being executed, including any 339 invoked functions, all the handlers in these statements are included on the search 340 path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and those further up the 341 stack from the guarded block. 341 invoked functions, all the handlers in these statements are included in the 342 search path. 343 Hence, if a termination exception is raised these handlers may be matched 344 against the exception and may handle it. 342 345 343 346 Exception matching checks the handler in each catch clause in the order 344 347 they appear, top to bottom. If the representation of the raised exception type 345 348 is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$ 346 (if provided) is bound to a pointer to the exception and the statements in347 @HANDLER_BLOCK@$_i$ are executed. 348 If control reaches the end of the handler, the exception is349 (if provided) is 350 bound to a pointer to the exception and the statements in @HANDLER_BLOCK@$_i$ 351 are executed. If control reaches the end of the handler, the exception is 349 352 freed and control continues after the try statement. 350 353 351 If no termination handler is found during the search ,the default handler352 (\defaultTerminationHandler) visible at the raise statement is called.353 Through \CFA's trait system , the best match at the raise sight isused.354 This function is run and is passed the copied exception. If the default355 handler returns, control continues after the throwstatement.354 If no termination handler is found during the search then the default handler 355 (\defaultTerminationHandler) visible at the raise statement is run. 356 Through \CFA's trait system the best match at the raise statement will be used. 357 This function is run and is passed the copied exception. 358 If the default handler is run control continues after the raise statement. 356 359 357 360 There is a global @defaultTerminationHandler@ that is polymorphic over all 358 termination exception types. Since it is so general, a more specific handler can be 361 termination exception types. 362 Since it is so general a more specific handler can be 359 363 defined and is used for those types, effectively overriding the handler 360 364 for a particular exception type. … … 370 374 matched a closure is taken from up the stack and executed, 371 375 after which the raising function continues executing. 372 These are most often used when a potentially repairable error occurs, some handler is found on the stack to fix it, and 373 the raising function can continue with the correction. 374 Another common usage is dynamic event analysis, \eg logging, without disrupting control flow. 375 Note, if an event is raised and there is no interest, control continues normally. 376 377 \PAB{We also have \lstinline{report} instead of \lstinline{throwResume}, \lstinline{recover} instead of \lstinline{catch}, and \lstinline{fixup} instead of \lstinline{catchResume}. 378 You may or may not want to mention it. You can still stick with \lstinline{catch} and \lstinline{throw/catchResume} in the thesis.} 376 The common uses for resumption exceptions include 377 potentially repairable errors, where execution can continue in the same 378 function once the error is corrected, and 379 ignorable events, such as logging where nothing needs to happen and control 380 should always continue from the same place. 379 381 380 382 A resumption raise is started with the @throwResume@ statement: … … 382 384 throwResume EXPRESSION; 383 385 \end{cfa} 386 \todo{Decide on a final set of keywords and use them everywhere.} 384 387 It works much the same way as the termination throw. 385 388 The expression must return a reference to a resumption exception, … … 387 390 @is_resumption_exception@ at the call site. 388 391 The assertions from this trait are available to 389 the exception system, while handling the exception. 390 391 Resumption does not need to copy the raised exception, as the stack is not unwound. 392 The exception and 393 any values on the stack remain in scope, while the resumption is handled. 394 395 The EHM then begins propogation. The search starts from the raise in the 396 resuming function and proceeds towards the base of the stack, from callee to caller. 392 the exception system while handling the exception. 393 394 At run-time, no exception copy is made. 395 Resumption does not unwind the stack nor otherwise remove values from the 396 current scope, so there is no need to manage memory to keep things in scope. 397 398 The EHM then begins propagation. The search starts from the raise in the 399 resuming function and proceeds towards the base of the stack, 400 from callee to caller. 397 401 At each stack frame, a check is made for resumption handlers defined by the 398 402 @catchResume@ clauses of a @try@ statement. … … 412 416 kind of raise. 413 417 When a try statement is executed, it simply executes the statements in the 414 @GUARDED_BLOCK@ and then returns.418 @GUARDED_BLOCK@ and then finishes. 415 419 416 420 However, while the guarded statements are being executed, including any 417 invoked functions, all the handlers in these statements are included on the search 418 path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and those further up the 419 stack from the guarded block. 421 invoked functions, all the handlers in these statements are included in the 422 search path. 423 Hence, if a resumption exception is raised these handlers may be matched 424 against the exception and may handle it. 420 425 421 426 Exception matching checks the handler in each catch clause in the order … … 427 432 the raise statement that raised the handled exception. 428 433 429 Like termination, if no resumption handler is found during the search, the default handler430 (\defaultResumptionHandler) visible at the raise statement is called. 431 It uses the best match at the 432 raise sight accordingto \CFA's overloading rules. The default handler is433 passed the exception given to the throw. When the default handler finishes434 Like termination, if no resumption handler is found during the search, 435 the default handler (\defaultResumptionHandler) visible at the raise 436 statement is called. It will use the best match at the raise sight according 437 to \CFA's overloading rules. The default handler is 438 passed the exception given to the raise. When the default handler finishes 434 439 execution continues after the raise statement. 435 440 436 There is a global \defaultResumptionHandler{} thatis polymorphic over all437 resumption exception types and preforms a termination throw on the exception.438 The \defaultTerminationHandler{} can be 439 customized by introducing a new or better match as well.441 There is a global \defaultResumptionHandler{} is polymorphic over all 442 resumption exceptions and preforms a termination throw on the exception. 443 The \defaultTerminationHandler{} can be overridden by providing a new 444 function that is a better match. 440 445 441 446 \subsubsection{Resumption Marking} 442 447 \label{s:ResumptionMarking} 443 444 448 A key difference between resumption and termination is that resumption does 445 449 not unwind the stack. A side effect that is that when a handler is matched 446 and run , its try block (the guarded statements) and every try statement447 searched before it are still on the stack. The ir existence can lead to the recursive448 resumption problem.450 and run it's try block (the guarded statements) and every try statement 451 searched before it are still on the stack. There presence can lead to 452 the recursive resumption problem. 449 453 450 454 The recursive resumption problem is any situation where a resumption handler … … 459 463 \end{cfa} 460 464 When this code is executed, the guarded @throwResume@ starts a 461 search and match s the handler in the @catchResume@ clause. This462 call is placed on the top of stack above the try-block. The second throw463 search s the same try block and puts callanother instance of the464 same handler on the stack leading to aninfinite recursion.465 search and matches the handler in the @catchResume@ clause. This 466 call is placed on the stack above the try-block. The second raise then 467 searches the same try block and puts another instance of the 468 same handler on the stack leading to infinite recursion. 465 469 466 470 While this situation is trivial and easy to avoid, much more complex cycles 467 471 can form with multiple handlers and different exception types. 468 472 469 To prevent all of these cases, the exception search marks the try statements it visits.470 A try statement is marked when a match check is preformed with it and an 471 exception. The statement is unmarked when the handling of that exception 472 is completed or the search completes without finding a handler.473 While a try statement is marked, its handlers are never matched, effecti fy474 skipping over themto the next try statement.473 To prevent all of these cases, a each try statement is ``marked" from the 474 time the exception search reaches it to either when the exception is being 475 handled completes the matching handler or when the search reaches the base 476 of the stack. 477 While a try statement is marked, its handlers are never matched, effectively 478 skipping over it to the next try statement. 475 479 476 480 \begin{center} … … 478 482 \end{center} 479 483 480 These rules mirror what happens with termination. 481 When a termination throw happens in a handler, the search does not look at 482 any handlers from the original throw to the original catch because that 483 part of the stack is unwound. 484 A resumption raise in the same situation wants to search the entire stack, 485 but with marking, the search does match exceptions for try statements at equivalent sections 486 that would have been unwound by termination. 487 488 The symmetry between resumption termination is why this pattern is picked. 489 Other patterns, such as marking just the handlers that caught the exception, also work but 490 lack the symmetry, meaning there are more rules to remember. 484 There are other sets of marking rules that could be used, 485 for instance, marking just the handlers that caught the exception, 486 would also prevent recursive resumption. 487 However, these rules mirror what happens with termination. 488 489 The try statements that are marked are the ones that would be removed from 490 the stack if this was a termination exception, that is those on the stack 491 between the handler and the raise statement. 492 This symmetry applies to the default handler as well, as both kinds of 493 default handlers are run at the raise statement, rather than (physically 494 or logically) at the bottom of the stack. 495 % In early development having the default handler happen after 496 % unmarking was just more useful. We assume that will continue. 491 497 492 498 \section{Conditional Catch} 493 494 499 Both termination and resumption handler clauses can be given an additional 495 500 condition to further control which exceptions they handle: … … 504 509 did not match. 505 510 506 The condition matching allows finer matching to check511 The condition matching allows finer matching by checking 507 512 more kinds of information than just the exception type. 508 513 \begin{cfa} … … 519 524 // Can't handle a failure relating to f2 here. 520 525 \end{cfa} 521 In this example , the file that experianced the IO error is used to decide526 In this example the file that experienced the IO error is used to decide 522 527 which handler should be run, if any at all. 523 528 … … 548 553 549 554 \subsection{Comparison with Reraising} 550 551 555 A more popular way to allow handlers to match in more detail is to reraise 552 556 the exception after it has been caught, if it could not be handled here. 553 On the surface these two features seem interchangable. 554 555 If @throw@ is used to start a termination reraise then these two statements 556 have the same behaviour: 557 On the surface these two features seem interchangeable. 558 559 If @throw;@ (no argument) starts a termination reraise, 560 which is the same as a raise but reuses the last caught exception, 561 then these two statements have the same behaviour: 557 562 \begin{cfa} 558 563 try { … … 574 579 } 575 580 \end{cfa} 576 However, if there are further handlers after this handler only the first is 577 check. For multiple handlers on a single try block that could handle the 578 same exception, the equivalent translations to conditional catch becomes more complex, resulting is multiple nested try blocks for all possible reraises. 579 So while catch-with-reraise is logically equivilant to conditional catch, there is a lexical explosion for the former. 580 581 \PAB{I think the following discussion makes an incorrect assumption. 582 A conditional catch CAN happen with the stack unwound. 583 Roy talked about this issue in Section 2.3.3 here: \newline 584 \url{http://plg.uwaterloo.ca/theses/KrischerThesis.pdf}} 585 586 Specifically for termination handling, a 587 conditional catch happens before the stack is unwound, but a reraise happens 588 afterwards. Normally this might only cause you to loose some debug 589 information you could get from a stack trace (and that can be side stepped 590 entirely by collecting information during the unwind). But for \CFA there is 591 another issue, if the exception is not handled the default handler should be 592 run at the site of the original raise. 593 594 There are two problems with this: the site of the original raise does not 595 exist anymore and the default handler might not exist anymore. The site is 596 always removed as part of the unwinding, often with the entirety of the 597 function it was in. The default handler could be a stack allocated nested 598 function removed during the unwind. 599 600 This means actually trying to pretend the catch didn't happening, continuing 601 the original raise instead of starting a new one, is infeasible. 602 That is the expected behaviour for most languages and we can't replicate 603 that behaviour. 581 That is, they will have the same behaviour in isolation. 582 Two things can expose differences between these cases. 583 584 One is the existence of multiple handlers on a single try statement. 585 A reraise skips all later handlers on this try statement but a conditional 586 catch does not. 587 Hence, if an earlier handler contains a reraise later handlers are 588 implicitly skipped, with a conditional catch they are not. 589 Still, they are equivalently powerful, 590 both can be used two mimic the behaviour of the other, 591 as reraise can pack arbitrary code in the handler and conditional catches 592 can put arbitrary code in the predicate. 593 % I was struggling with a long explanation about some simple solutions, 594 % like repeating a condition on later handlers, and the general solution of 595 % merging everything together. I don't think it is useful though unless its 596 % for a proof. 597 % https://en.cppreference.com/w/cpp/language/throw 598 599 The question then becomes ``Which is a better default?" 600 We believe that not skipping possibly useful handlers is a better default. 601 If a handler can handle an exception it should and if the handler can not 602 handle the exception then it is probably safer to have that explicitly 603 described in the handler itself instead of implicitly described by its 604 ordering with other handlers. 605 % Or you could just alter the semantics of the throw statement. The handler 606 % index is in the exception so you could use it to know where to start 607 % searching from in the current try statement. 608 % No place for the `goto else;` metaphor. 609 610 The other issue is all of the discussion above assumes that the only 611 way to tell apart two raises is the exception being raised and the remaining 612 search path. 613 This is not true generally, the current state of the stack can matter in 614 a number of cases, even only for a stack trace after an program abort. 615 But \CFA has a much more significant need of the rest of the stack, the 616 default handlers for both termination and resumption. 617 618 % For resumption it turns out it is possible continue a raise after the 619 % exception has been caught, as if it hadn't been caught in the first place. 620 This becomes a problem combined with the stack unwinding used in termination 621 exception handling. 622 The stack is unwound before the handler is installed, and hence before any 623 reraises can run. So if a reraise happens the previous stack is gone, 624 the place on the stack where the default handler was supposed to run is gone, 625 if the default handler was a local function it may have been unwound too. 626 There is no reasonable way to restore that information, so the reraise has 627 to be considered as a new raise. 628 This is the strongest advantage conditional catches have over reraising, 629 they happen before stack unwinding and avoid this problem. 630 631 % The one possible disadvantage of conditional catch is that it runs user 632 % code during the exception search. While this is a new place that user code 633 % can be run destructors and finally clauses are already run during the stack 634 % unwinding. 635 % 636 % https://www.cplusplus.com/reference/exception/current_exception/ 637 % `exception_ptr current_exception() noexcept;` 638 % https://www.python.org/dev/peps/pep-0343/ 604 639 605 640 \section{Finally Clauses} 606 641 \label{s:FinallyClauses} 607 608 642 Finally clauses are used to preform unconditional clean-up when leaving a 609 643 scope and are placed at the end of a try statement after any handler clauses: … … 618 652 The @FINALLY_BLOCK@ is executed when the try statement is removed from the 619 653 stack, including when the @GUARDED_BLOCK@ finishes, any termination handler 620 finishes ,or during an unwind.654 finishes or during an unwind. 621 655 The only time the block is not executed is if the program is exited before 622 656 the stack is unwound. … … 634 668 635 669 Not all languages with unwinding have finally clauses. Notably \Cpp does 636 without it as destructors with RAII serve a similar role. Although destructors and 637 finally clauses have overlapping usage cases, they have their own 638 specializations, like top-level functions and lambda functions with closures. 639 Destructors take more work if a number of unrelated, local variables without destructors or dynamically allocated variables must be passed for de-intialization. 640 Maintaining this destructor during local-block modification is a source of errors. 641 A finally clause places local de-intialization inline with direct access to all local variables. 670 without it as descructors, and the RAII design pattern, serve a similar role. 671 Although destructors and finally clauses can be used in the same cases, 672 they have their own strengths, similar to top-level function and lambda 673 functions with closures. 674 Destructors take more work for their first use, but if there is clean-up code 675 that needs to be run every time a type is used they soon become much easier 676 to set-up. 677 On the other hand finally clauses capture the local context, so is easy to 678 use when the clean-up is not dependent on the type of a variable or requires 679 information from multiple variables. 680 % To Peter: I think these are the main points you were going for. 642 681 643 682 \section{Cancellation} … … 652 691 raise, this exception is not used in matching only to pass information about 653 692 the cause of the cancellation. 654 (This restrictionalso means matching cannot fail so there is no default handler.)693 (This also means matching cannot fail so there is no default handler.) 655 694 656 695 After @cancel_stack@ is called the exception is copied into the EHM's memory 657 and the current stack is 658 unwound. 659 The result of a cancellation depends on the kind of stack that is being unwound. 696 and the current stack is unwound. 697 The behaviour after that depends on the kind of stack being cancelled. 660 698 661 699 \paragraph{Main Stack} … … 664 702 After the main stack is unwound there is a program-level abort. 665 703 666 There are two reasons for this semantics. The first is that it obviously had to do the abort 704 There are two reasons for these semantics. 705 The first is that it had to do this abort. 667 706 in a sequential program as there is nothing else to notify and the simplicity 668 707 of keeping the same behaviour in sequential and concurrent programs is good. 669 \PAB{I do not understand this sentence. $\Rightarrow$ Also, even in concurrent programs, there is no stack that an innate connection 670 to, so it would have be explicitly managed.} 708 Also, even in concurrent programs there may not currently be any other stacks 709 and even if other stacks do exist, main has no way to know where they are. 671 710 672 711 \paragraph{Thread Stack} … … 680 719 and an implicit join (from a destructor call). The explicit join takes the 681 720 default handler (@defaultResumptionHandler@) from its calling context while 682 the implicit join provides its own ,which does a program abort if the721 the implicit join provides its own; which does a program abort if the 683 722 @ThreadCancelled@ exception cannot be handled. 684 723 685 \PAB{Communication can occur during the lifetime of a thread using shared variable and \lstinline{waitfor} statements. 686 Are you sure you mean communication here? Maybe you mean synchronization (rendezvous) point. $\Rightarrow$ Communication is done at join because a thread only has two points of 687 communication with other threads: start and join.}724 The communication and synchronization are done here because threads only have 725 two structural points (not dependent on user-code) where 726 communication/synchronization happens: start and join. 688 727 Since a thread must be running to perform a cancellation (and cannot be 689 728 cancelled from another stack), the cancellation must be after start and 690 before the join, so join is use .729 before the join, so join is used. 691 730 692 731 % TODO: Find somewhere to discuss unwind collisions. … … 695 734 a destructor and prevents cascading the error across multiple threads if 696 735 the user is not equipped to deal with it. 697 Also you can always add an explicit join if that is the desired behaviour. 736 It is always possible to add an explicit join if that is the desired behaviour. 737 738 With explicit join and a default handler that triggers a cancellation, it is 739 possible to cascade an error across any number of threads, cleaning up each 740 in turn, until the error is handled or the main thread is reached. 698 741 699 742 \paragraph{Coroutine Stack} … … 701 744 satisfies the @is_coroutine@ trait. 702 745 After a coroutine stack is unwound, control returns to the @resume@ function 703 that most recently resumed it. The resumereports a704 @CoroutineCancelled@ exception, which contains references to the cancelled746 that most recently resumed it. @resume@ reports a 747 @CoroutineCancelled@ exception, which contains a references to the cancelled 705 748 coroutine and the exception used to cancel it. 706 749 The @resume@ function also takes the \defaultResumptionHandler{} from the 707 caller's context and passes it to the internal cancellation.750 caller's context and passes it to the internal report. 708 751 709 752 A coroutine knows of two other coroutines, its starter and its last resumer. … … 711 754 (in terms of coroutine state) called resume on this coroutine, so the message 712 755 is passed to the latter. 756 757 With a default handler that triggers a cancellation, it is possible to 758 cascade an error across any number of coroutines, cleaning up each in turn, 759 until the error is handled or a thread stack is reached. -
doc/theses/andrew_beach_MMath/future.tex
r6ba6846 rb680198 3 3 4 4 \section{Language Improvements} 5 \todo{Future/Language Improvements seems to have gotten mixed up. It is 6 presented as ``waiting on language improvements" but really its more 7 non-research based impovements.} 5 8 \CFA is a developing programming language. As such, there are partially or 6 9 unimplemented features of the language (including several broken components) … … 11 14 \item 12 15 The implementation of termination is not portable because it includes 13 hand-crafted assembly statements. These sections must be ported by hand to 16 hand-crafted assembly statements. 17 The existing compilers cannot translate that for other platforms and those 18 sections must be ported by hand to 14 19 support more hardware architectures, such as the ARM processor. 15 \PAB{I think this is a straw-man problem because the hand-coded assembler code16 has to be generated somewhere, and that somewhere is hand-coded.}17 20 \item 18 21 Due to a type-system problem, the catch clause cannot bind the exception to a … … 30 33 There is no detection of colliding unwinds. It is possible for clean-up code 31 34 run during an unwind to trigger another unwind that escapes the clean-up code 32 itself , \eg,a termination exception caught further down the stack or a33 cancellation. There do exist ways to handle this issue,but currently they are not34 even detected and the first unwind is simply dropped, often leaving35 it in a bad state. \Cpp terminates the program in this case, and Java picks the ...35 itself; such as a termination exception caught further down the stack or a 36 cancellation. There do exist ways to handle this but currently they are not 37 even detected and the first unwind will simply be forgotten, often leaving 38 it in a bad state. 36 39 \item 37 40 Also the exception system did not have a lot of time to be tried and tested. … … 69 72 bad software engineering. 70 73 71 Non-local/concurrent raise requires more coordination between the concurrency system 74 Non-local/concurrent raise requires more 75 coordination between the concurrency system 72 76 and the exception system. Many of the interesting design decisions centre 73 77 around masking, \ie controlling which exceptions may be thrown at a stack. It … … 94 98 passed on. 95 99 96 However checked exceptions were never seriously considered for this project because97 they have significant usability and reuse trade-offsin100 However checked exceptions were never seriously considered for this project 101 because they have significant trade-offs in usablity and code reuse in 98 102 exchange for the increased safety. 99 103 These trade-offs are most problematic when trying to pass exceptions through … … 103 107 over safety design) so additional research is needed. 104 108 105 Follow-up work might find a compromise design for checked exceptions in \CFA, possibly using 106 polymorphic exception signatures, a form of tunneling\cite{Zhang19}, or 109 Follow-up work might add some form of checked exceptions to \CFA, 110 possibly using polymorphic exception signatures, 111 a form of tunneling\cite{Zhang19} or 107 112 checked and unchecked raises. 108 113 … … 148 153 For instance, resumption could be extended to cover this use by allowing local 149 154 control flow out of it. This approach would require an unwind as part of the 150 transition as there are stack frames that have to be removed back to the resumption handler. This approach 151 means no special statement is required in the handler to continue after it. 152 Currently, \CFA allows a termination exception to be thrown from within any resumption handler so 153 there is already a way to partially mimic signal exceptions. 155 transition as there are stack frames that have to be removed between where 156 the resumption handler is installed and where it is defined. 157 This approach would not require, but might benefit from, a special statement 158 to leave the handler. 159 Currently, mimicking this behaviour in \CFA is possible by throwing a 160 termination inside a resumption handler. 154 161 155 162 % Maybe talk about the escape; and escape CONTROL_STMT; statements or how -
doc/theses/andrew_beach_MMath/implement.tex
r6ba6846 rb680198 17 17 pointer to the virtual table, which is called the \emph{virtual-table pointer}. 18 18 Internally, the field is called \snake{virtual_table}. 19 The field is fixed after construction and is the first field in the19 The field is fixed after construction. It is always the first field in the 20 20 structure so that its location is always known. 21 21 \todo{Talk about constructors for virtual types (after they are working).} 22 22 23 The virtual-table pointer is what binds an instance of a virtual type to its virtual table. This 24 pointer is used as an identity check, and to access the 23 The virtual table pointer binds an instance of a virtual type 24 to a virtual table. 25 The pointer is also the table's id and how the system accesses the 25 26 virtual table and the virtual members there. 26 27 27 28 \subsection{Type Id} 28 29 Every virtual type has a unique id. 29 Type ids can be compared for equality (\ie the types represented are the same) 30 Type ids can be compared for equality, 31 which checks if the types reperented are the same, 30 32 or used to access the type's type information. 31 33 The type information currently is only the parent's type id or, if the 32 type has no parent, @0p@.34 type has no parent, the null pointer. 33 35 34 36 The id's are implemented as pointers to the type's type information instance. 35 37 Dereferencing the pointer gets the type information. 36 The ancestors of a virtual type are found by traversing t he type idthrough38 The ancestors of a virtual type are found by traversing type ids through 37 39 the type information. 38 An id alsopushes the issue of creating a unique value (for40 The information pushes the issue of creating a unique value (for 39 41 the type id) to the problem of creating a unique instance (for type 40 42 information), which the linker can solve. 41 43 42 Advanced linker support is required because there is no place that appears 43 only once to attach the type information to. There should be one structure 44 definition but it is included in multiple translation units because of separate compilation. Each virtual 45 table definition should be unique but there are an arbitrary number of these, 46 so the special section prefix \texttt{.gnu.linkonce} is used. 47 With a generated unique suffix (making the entire section name unique) the linker 48 removes multiple definition ensuring only one version exists after linking. 49 Then it is just a matter of making sure there is a unique name for each type. 50 51 These steps are done in three phases. 44 The advanced linker support is used here to avoid having to create 45 a new declaration to attach this data to. 46 With C/\CFA's header/implementation file divide for something to appear 47 exactly once it must come from a declaration that appears in exactly one 48 implementation file; the declarations in header files may exist only once 49 they can be included in many different translation units. 50 Therefore, structure's declaration will not work. 51 Neither will attaching the type information to the virtual table -- although 52 a vtable declarations are in implemention files they are not unique, see 53 \autoref{ss:VirtualTable}. 54 Instead the same type information is generated multiple times and then 55 the new attribute \snake{cfa_linkone} is used to removed duplicates. 56 57 Type information is constructed as follows: 52 58 \begin{enumerate} 53 59 \item 54 The first phase is to generate a new structure definition to store the type 60 Use the type's name to generate a name for the type information structure. 61 This is saved so it may be reused. 62 \item 63 Generate a new structure definition to store the type 55 64 information. The layout is the same in each case, just the parent's type id, 56 but the types are changed.57 The structure's name is change, it is based off the virtual type's name, and58 the type of the parent's type id.59 If the virtual type is polymorphic ,then the type information structure is65 but the types used change from instance to instance. 66 The generated name is used for both this structure and, if relivant, the 67 parent pointer. 68 If the virtual type is polymorphic then the type information structure is 60 69 polymorphic as well, with the same polymorphic arguments. 61 70 \item 62 The second phase is to generate an instance of the type information with a 63 almost unique name, generated by mangling the virtual type name. 71 A seperate name for instances is generated from the type's name. 64 72 \item 65 The third phase is implicit with \CFA's overloading scheme. \CFA mangles 66 names with type information so that all of the symbols exported to the linker 67 are unique even if in the \CFA code they are the same. Having two declarations 68 with the same name and same type is forbidden because it is impossible for 69 overload resolution to pick between them. This is the reason why a unique type is 70 generated for each virtual type. 71 Polymorphic information is included in this mangling so polymorphic 72 types have separate instances for each set of polymorphic arguments. 73 The definition is generated and initialised. 74 The parent id is set to the null pointer or to the address of the parent's 75 type information instance. Name resolution handles the rest. 76 \item 77 \CFA's name mangler does its regular name mangling encoding the type of 78 the declaration into the instance name. This gives a completely unique name 79 including different instances of the same polymorphic type. 73 80 \end{enumerate} 74 The following example shows the components for a generated virtual type. 75 \begin{cfa} 76 struct TYPE_ID_TYPE { 77 PARENT_ID_TYPE const * parent; 81 \todo{The list is making me realise, some of this isn't ordered.} 82 83 Writing that code manually, with helper macros for the early name mangling, 84 would look like this: 85 \begin{cfa} 86 struct INFO_TYPE(TYPE) { 87 INFO_TYPE(PARENT) const * parent; 78 88 }; 79 89 80 90 __attribute__((cfa_linkonce)) 81 TYPE_ID_TYPE const TYPE_ID_NAME= {82 & PARENT_ID_NAME,91 INFO_TYPE(TYPE) const INFO_NAME(TYPE) = { 92 &INFO_NAME(PARENT), 83 93 }; 84 94 \end{cfa} 85 95 86 \subsubsection{\lstinline{cfa_linkonce} Attribute} 96 \subsubsection{\lstinline{cfa\_linkonce} Attribute} 97 % I just realised: This is an extension of the inline keyword. 98 % An extension of C's at least, it is very similar to C++'s. 87 99 Another feature added to \CFA is a new attribute: \texttt{cfa\_linkonce}. 88 100 This attribute is attached to an object or function definition 89 101 (any global declaration with a name and a type) 90 102 allowing it to be defined multiple times. 91 All matching definitions must have the link-once attribute on them and should 92 be identical. 93 This attributed prototype is placed in a header file with other 94 forward declaration. 95 96 This technique is used for type-id instances, as there is no unique location 97 associated with a type, except for the type definition in a header. 98 The result is the unique type-id object generated by the linker. 103 All matching definitions mush have the link-once attribute 104 and their implementations should be identical as well. 105 106 A single definition with the attribute can be included in a header 107 file as if it was a forward declaration, except no definition is required. 108 109 This technique is used for type-id instances. A link-once definition is 110 generated each time the structure is seen. This will result in multiple 111 copies but the link-once attribute ensures all but one are removed for a 112 unique instance. 99 113 100 114 Internally, @cfa_linkonce@ is replaced with 101 115 @section(".gnu.linkonce.NAME")@ where \texttt{NAME} is replaced by the 102 116 mangled name of the object. 103 Any other @section@ attributes are alsoremoved from the declaration.117 Any other @section@ attributes are removed from the declaration. 104 118 The prefix \texttt{.gnu.linkonce} in section names is recognized by the 105 linker. If two of these sections appear with the same name, including everything106 that comes after the special prefix, then only one is used and the other 107 discarded.119 linker. If two of these sections appear with the same name, including 120 everything that comes after the special prefix, then only one is used 121 and the other is discarded. 108 122 109 123 \subsection{Virtual Table} 124 \label{ss:VirtualTable} 110 125 Each virtual type has a virtual table type that stores its type id and 111 126 virtual members. … … 115 130 below. 116 131 117 Figure~\ref{f:VirtualTableLayout} shows the layout is in three parts. 118 \PAB{Number the parts in the figure.} 119 \begin{enumerate} 120 \item 132 The layout always comes in three parts. 133 \todo{Add labels to the virtual table layout figure.} 121 134 The first section is just the type id at the head of the table. It is always 122 there to ensure that \PAB{... missing text to end this sentence}123 \item 135 there to ensure that it can be found even when the accessing code does not 136 know which virtual type it has. 124 137 The second section are all the virtual members of the parent, in the same 125 138 order as they appear in the parent's virtual table. Note that the type may 126 change slightly as references to the @this@ change. This structureis limited to139 change slightly as references to the ``this" will change. This is limited to 127 140 inside pointers/references and via function pointers so that the size (and 128 141 hence the offsets) are the same. 129 \item130 142 The third section is similar to the second except that it is the new virtual 131 143 members introduced at this level in the hierarchy. 132 \end{enumerate}133 144 134 145 \begin{figure} … … 142 153 prefix that has the same layout and types as its parent virtual table. 143 154 This, combined with the fixed offset to the virtual table pointer, means that 144 for any virtual type, it or any of its 145 descendants can be accessed through 146 the virtual table pointer. 147 From there, it is safe to check the type id to identify the exact type of the 148 underlying object, access any of the virtual members, and pass the object to 155 for any virtual type, it is always safe to access its virtual table and, 156 from there, it is safe to check the type id to identify the exact type of the 157 underlying object, access any of the virtual members and pass the object to 149 158 any of the method-like virtual members. 150 159 … … 153 162 the context of the declaration. 154 163 155 The type id is always fixed with each virtual table type having164 The type id is always fixed; with each virtual table type having 156 165 exactly one possible type id. 157 The virtual members are usually filled in during type resolution. The best match for158 a given name and type at the declaration site is used.159 There are two exceptions to that rule: the @size@ field is the type's size160 set using a @sizeof@ expression, and the @align@ field isthe161 type's alignment set using an @alignof@ expression.166 The virtual members are usually filled in by type resolution. 167 The best match for a given name and type at the declaration site is used. 168 There are two exceptions to that rule: the @size@ field, the type's size, 169 is set using a @sizeof@ expression and the @align@ field, the 170 type's alignment, is set using an @alignof@ expression. 162 171 163 172 \subsubsection{Concurrency Integration} … … 168 177 at the definition of the main function. 169 178 170 Figure~\ref{f:ConcurrencyTransformations} shows ... 171 \ todo{Improve Concurrency Transformations figure.}179 This is showned through code re-writing in 180 \autoref{f:ConcurrencyTransformations}. 172 181 173 182 \begin{figure} … … 206 215 \label{f:ConcurrencyTransformations} 207 216 \end{figure} 217 \todo{Improve Concurrency Transformations figure.} 208 218 209 219 \subsection{Virtual Cast} … … 222 232 the cast target is passed in as @child@. 223 233 224 Thegenerated C code wraps both arguments and the result with type casts.234 For generated C code wraps both arguments and the result with type casts. 225 235 There is also an internal check inside the compiler to make sure that the 226 236 target type is a virtual type. 227 237 % It also checks for conflicting definitions. 228 238 229 The virtual cast either returns the original pointer as a new type or 0p. 230 So the function just does the parent check and returns the appropriate value. 239 The virtual cast either returns the original pointer or the null pointer 240 as the new type. 241 So the function does the parent check and returns the appropriate value. 231 242 The parent check is a simple linear search of child's ancestors using the 232 243 type information. … … 257 268 Allocating/deallocating stack space is usually an $O(1)$ operation achieved by 258 269 bumping the hardware stack-pointer up or down as needed. 259 In fact, constructing/destructing values within a stack frame is of similar complexity but often takes longer. 270 Constructing/destructing values within a stack frame has 271 a similar complexity but can add additional work and take longer. 260 272 261 273 Unwinding across multiple stack frames is more complex because that 262 274 information is no longer contained within the current function. 263 With sep arate compilation a function has no way of knowing what its callers264 so it can not know how large those frames are.265 Without altering the main code path ,it is also hard to pass that work off275 With seperate compilation a function has no way of knowing what its callers 276 are so it can't know how large those frames are. 277 Without altering the main code path it is also hard to pass that work off 266 278 to the caller. 267 279 … … 272 284 stack. It is up to the programmer to ensure the snap-shot is valid when it is 273 285 reset and that all required clean-up from the unwound stacks is performed. 274 This approach is fragile and forces extra work in the surrounding code.275 276 With respect to the extra work in the sur rounding code,286 This approach is fragile and requires extra work in the surrounding code. 287 288 With respect to the extra work in the surounding code, 277 289 many languages define clean-up actions that must be taken when certain 278 290 sections of the stack are removed. Such as when the storage for a variable 279 is removed from the stack or when a @try@statement with a finally clause is291 is removed from the stack or when a try statement with a finally clause is 280 292 (conceptually) popped from the stack. 281 None of these should be handled explicitlyby the user --- that would contradict the293 None of these should be handled by the user --- that would contradict the 282 294 intention of these features --- so they need to be handled automatically. 283 295 … … 308 320 instruction pointer is within a region's start/end, then execution is currently 309 321 executing in that region. Regions are used to mark out the scopes of objects 310 with destructors and @try@blocks.322 with destructors and try blocks. 311 323 312 324 % Libunwind actually does very little, it simply moves down the stack from … … 326 338 The attribute is used on a variable and specifies a function, 327 339 in this case @clean_up@, run when the variable goes out of scope. 328 This capability is enough to mimic destructors, but not @try@ statements which can effect 340 This feature is enough to mimic destructors, 341 but not try statements which can effect 329 342 the unwinding. 330 343 331 To get full unwinding support, all of these components must done directly with332 assembly and assembler directives, particularly the cfi directives333 \snake{.cfi_ Leda} and \snake{.cfi_personality}.344 To get full unwinding support, all of these features must be handled directly 345 in assembly and assembler directives; partiularly the cfi directives 346 \snake{.cfi_lsda} and \snake{.cfi_personality}. 334 347 335 348 \subsection{Personality Functions} … … 375 388 The @exception_class@ argument is a copy of the 376 389 \code{C}{exception}'s @exception_class@ field, 377 which is a number that identifies the exception handling mechanism that created378 th e \PAB{... missing text to end this sentence}390 which is a number that identifies the exception handling mechanism 391 that created the exception. 379 392 380 393 The \code{C}{exception} argument is a pointer to a user … … 392 405 messages for special cases (some of which should never be used by the 393 406 personality function) and error codes. However, unless otherwise noted, the 394 personality function always return @_URC_CONTINUE_UNWIND@.407 personality function always returns @_URC_CONTINUE_UNWIND@. 395 408 396 409 \subsection{Raise Exception} 397 Raising an exception is the central function of libunwind and it performs the410 Raising an exception is the central function of libunwind and it performs 398 411 two-staged unwinding. 399 412 \begin{cfa} … … 485 498 \Cpp exceptions closely. The main complication for \CFA is that the 486 499 compiler generates C code, making it very difficult to generate the assembly to 487 form the LSDA for @try@blocks or destructors.500 form the LSDA for try blocks or destructors. 488 501 489 502 \subsection{Memory Management} … … 500 513 \label{f:ExceptionLayout} 501 514 \end{figure} 502 \todo*{Convert the exception layout to an actual diagram.} 503 504 Exceptions are stored in variable-sized blocks (see Figure~\vref{f:ExceptionLayout}).515 516 Exceptions are stored in variable-sized blocks 517 (see \autoref{f:ExceptionLayout}). 505 518 The first component is a fixed-sized data structure that contains the 506 519 information for libunwind and the exception system. The second component is an … … 517 530 high enough), which must be allocated. The previous exceptions may not be 518 531 freed because the handler/catch clause has not been run. 519 Therefore, the EHM must keep all of these exceptions alive while it allocates exceptions for new throws. 532 Therefore, the EHM must keep all unhandled exceptions alive 533 while it allocates exceptions for new throws. 520 534 521 535 \begin{figure} … … 584 598 exception into managed memory. After the exception is handled, the free 585 599 function is used to clean up the exception and then the entire node is 586 passed to free so the memory is returnedto the heap.600 passed to free, returning the memory back to the heap. 587 601 588 602 \subsection{Try Statements and Catch Clauses} 589 The @try@ statement with termination handlers is complex because it must 590 compensate for the C code-generation versus assembly-code generation from \CFA. Libunwind 603 The try statement with termination handlers is complex because it must 604 compensate for the C code-generation versus 605 assembly-code generated from \CFA. Libunwind 591 606 requires an LSDA and personality function for control to unwind across a 592 607 function. The LSDA in particular is hard to mimic in generated C code. 593 608 594 609 The workaround is a function called @__cfaehm_try_terminate@ in the standard 595 library. The contents of a @try@block and the termination handlers are converted610 library. The contents of a try block and the termination handlers are converted 596 611 into functions. These are then passed to the try terminate function and it 597 612 calls them. 598 613 Because this function is known and fixed (and not an arbitrary function that 599 happens to contain a @try@statement), the LSDA can be generated ahead614 happens to contain a try statement), the LSDA can be generated ahead 600 615 of time. 601 616 … … 603 618 embedded assembly. This assembly code is handcrafted using C @asm@ statements 604 619 and contains 605 enough information for a single @try@ statement the function represents.620 enough information for a single try statement the function repersents. 606 621 607 622 The three functions passed to try terminate are: 608 623 \begin{description} 609 \item[try function:] This function is the @try@ block, where all the code inside the610 @try@ block is wrapped inside the function. It takes no parameters and has no624 \item[try function:] This function is the try block, it is where all the code 625 from inside the try block is placed. It takes no parameters and has no 611 626 return value. This function is called during regular execution to run the try 612 627 block. … … 620 635 handler that matches the exception. 621 636 622 \item[handler function:] This function handles the exception, where the code inside623 is constructed by stitching together the bodies of 624 each handler of a @try@ statement and dispatches to the selected handler.637 \item[handler function:] This function handles the exception, and contains 638 all the code from the handlers in the try statement, joined with a switch 639 statement on the handler's id. 625 640 It takes a 626 641 pointer to the exception and the handler's id and returns nothing. It is called … … 628 643 \end{description} 629 644 All three functions are created with GCC nested functions. GCC nested functions 630 can be used to create closures, \ie functions that can refer to the state of other 645 can be used to create closures, 646 in other words functions that can refer to the state of other 631 647 functions on the stack. This approach allows the functions to refer to all the 632 648 variables in scope for the function containing the @try@ statement. These … … 636 652 Using this pattern, \CFA implements destructors with the cleanup attribute. 637 653 638 Figure~\ref{f:TerminationTransformation} shows an example transformation for a \CFA @try@ 639 statement with @catch@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.} 654 \autoref{f:TerminationTransformation} shows the pattern used to transform 655 a \CFA try statement with catch clauses into the approprate C functions. 656 \todo{Explain the Termination Transformation figure.} 640 657 641 658 \begin{figure} … … 653 670 \hrule 654 671 \medskip 672 \todo*{Termination Transformation divider feels too strong.} 655 673 656 674 \begin{cfa} … … 707 725 Instead of storing the data in a special area using assembly, 708 726 there is just a linked list of possible handlers for each stack, 709 with each list node representing a @try@statement on the stack.727 with each node on the list reperenting a try statement on the stack. 710 728 711 729 The head of the list is stored in the exception context. 712 The nodes are stored in order, with the more recent @try@statements closer730 The nodes are stored in order, with the more recent try statements closer 713 731 to the head of the list. 714 732 Instead of traversing the stack, resumption handling traverses the list. 715 At each node, the EHM checks to see if the @try@ statement it represents733 At each node, the EHM checks to see if the try statement the node repersents 716 734 can handle the exception. If it can, then the exception is handled and 717 735 the operation finishes, otherwise the search continues to the next node. 718 If the search reaches the end of the list without finding a @try@statement736 If the search reaches the end of the list without finding a try statement 719 737 that can handle the exception, the default handler is executed and the 720 738 operation finishes. … … 724 742 if the exception is handled and false otherwise. 725 743 726 For each @catchResume@ clause, the handler function: 727 \begin{itemize} 728 \item 729 checks to see if the raised exception is a descendant type of the declared 730 exception type, 731 \item 732 if it is and there is a conditional expression then it 733 runs the test, 734 \item 735 if both checks pass the handling code for the clause is run and the function returns true, 736 \item 737 otherwise it moves onto the next clause. 738 \end{itemize} 739 If this is the last @catchResume@ clause then instead of moving onto 740 the next clause the function returns false as no handler could be found. 741 742 Figure~\ref{f:ResumptionTransformation} shows an example transformation for a \CFA @try@ 743 statement with @catchResume@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.} 744 The handler function checks each of its internal handlers in order, 745 top-to-bottom, until it funds a match. If a match is found that handler is 746 run, after which the function returns true, ignoring all remaining handlers. 747 If no match is found the function returns false. 748 The match is performed in two steps, first a virtual cast is used to see 749 if the thrown exception is an instance of the declared exception or one of 750 its descendant type, then check to see if passes the custom predicate if one 751 is defined. This ordering gives the type guarantee used in the predicate. 752 753 \autoref{f:ResumptionTransformation} shows the pattern used to transform 754 a \CFA try statement with catch clauses into the approprate C functions. 755 \todo{Explain the Resumption Transformation figure.} 744 756 745 757 \begin{figure} … … 753 765 } 754 766 \end{cfa} 767 768 \medskip 769 \hrule 770 \medskip 771 \todo*{Resumption Transformation divider feels too strong.} 755 772 756 773 \begin{cfa} … … 784 801 785 802 % Recursive Resumption Stuff: 786 Figure~\ref{f:ResumptionMarking} shows the search skipping (see \vpageref{s:ResumptionMarking}), which ignores parts of 803 \autoref{f:ResumptionMarking} shows search skipping 804 (see \vpageref{s:ResumptionMarking}), which ignores parts of 787 805 the stack 788 806 already examined, is accomplished by updating the front of the list as the … … 790 808 is updated to the next node of the current node. After the search is complete, 791 809 successful or not, the head of the list is reset. 810 % No paragraph? 792 811 This mechanism means the current handler and every handler that has already 793 812 been checked are not on the list while a handler is run. If a resumption is 794 813 thrown during the handling of another resumption, the active handlers and all 795 814 the other handler checked up to this point are not checked again. 815 % No paragraph? 796 816 This structure also supports new handlers added while the resumption is being 797 817 handled. These are added to the front of the list, pointing back along the 798 stack -- the first one points over all the checked handlers -- and the ordering 799 is maintained. 800 \PAB{Maybe number the figure and use the numbers in the description to help the reader follow.} 818 stack --- the first one points over all the checked handlers --- 819 and the ordering is maintained. 801 820 802 821 \begin{figure} … … 804 823 \caption{Resumption Marking} 805 824 \label{f:ResumptionMarking} 806 \todo*{ Convert Resumption Marking into a line figure.}825 \todo*{Label Resumption Marking to aid clarity.} 807 826 \end{figure} 808 827 809 828 \label{p:zero-cost} 810 Finally, the resumption implementation has a cost for entering/exiting a @try@811 statement with @catchResume@ clauses, whereas a @try@statement with @catch@829 Finally, the resumption implementation has a cost for entering/exiting a try 830 statement with @catchResume@ clauses, whereas a try statement with @catch@ 812 831 clauses has zero-cost entry/exit. While resumption does not need the stack 813 832 unwinding and cleanup provided by libunwind, it could use the search phase to … … 828 847 around the context of the associated @try@ statement. 829 848 830 The rest is handled by GCC. The @try@block and all handlers are inside this849 The rest is handled by GCC. The try block and all handlers are inside this 831 850 block. At completion, control exits the block and the empty object is cleaned 832 851 up, which runs the function that contains the finally code. … … 840 859 841 860 The first step of cancellation is to find the cancelled stack and its type: 842 coroutine or thread. Fortunately, the thread library stores the main thread 843 pointer and the current thread pointer, and every thread stores a pointer to 844 its coroutine and the coroutine it is currently executing. 861 coroutine, thread or main thread. 862 In \CFA, a thread (the construct the user works with) is a user-level thread 863 (point of execution) paired with a coroutine, the thread's main coroutine. 864 The thread library also stores pointers to the main thread and the current 865 thread. 845 866 If the current thread's main and current coroutines are the same then the 846 867 current stack is a thread stack, otherwise it is a coroutine stack. 847 Note, the runtime considers a thread as a coroutine with an associated user-level thread; 848 hence, for many operations a thread and coroutine are treated uniformly. 849 %\todo*{Consider adding a description of how threads are coroutines.} 850 851 % Furthermore it is easy to compare the 852 % current thread to the main thread to see if they are the same. And if this 853 % is not a thread stack then it must be a coroutine stack. 868 If the current stack is a thread stack, it is also the main thread stack 869 if and only if the main and current threads are the same. 854 870 855 871 However, if the threading library is not linked, the sequential execution is on … … 861 877 passed to the forced-unwind function. The general pattern of all three stop 862 878 functions is the same: continue unwinding until the end of stack and 863 then p erform the appropriate transfer.879 then preform the appropriate transfer. 864 880 865 881 For main stack cancellation, the transfer is just a program abort. … … 872 888 cancelled exception. It is then resumed as a regular exception with the default 873 889 handler coming from the context of the resumption call. 874 This semantics allows a cancellation to cascade through an arbitrary set of resumed875 coroutines back to the thread's coroutine, performing cleanup along the way.876 890 877 891 For thread cancellation, the exception is stored on the thread's main stack and … … 883 897 null (as it is for the auto-generated joins on destructor call), the default is 884 898 used, which is a program abort. 885 This semantics allows a cancellation to cascade through an arbitrary set of joining886 threads back to the program's main, performing cleanup along the way.887 899 %; which gives the required handling on implicate join. -
doc/theses/andrew_beach_MMath/intro.tex
r6ba6846 rb680198 1 1 \chapter{Introduction} 2 2 3 \PAB{Stay in the present tense. \newline 4 \url{https://plg.uwaterloo.ca/~pabuhr/technicalWriting.shtml}} 5 \newline 6 \PAB{Note, \lstinline{lstlisting} normally bolds keywords. None of the keywords in your thesis are bolded.} 7 8 % Talk about Cforall and exceptions generally. 9 %This thesis goes over the design and implementation of the exception handling 10 %mechanism (EHM) of 11 %\CFA (pernounced sea-for-all and may be written Cforall or CFA). 12 Exception handling provides alternative dynamic inter-function control flow. 3 % The highest level overview of Cforall and EHMs. Get this done right away. 4 This thesis goes over the design and implementation of the exception handling 5 mechanism (EHM) of 6 \CFA (pronounced sea-for-all and may be written Cforall or CFA). 7 \CFA is a new programming language that extends C, that maintains 8 backwards-compatibility while introducing modern programming features. 9 Adding exception handling to \CFA gives it new ways to handle errors and 10 make other large control-flow jumps. 11 12 % Now take a step back and explain what exceptions are generally. 13 Exception handling provides dynamic inter-function control flow. 13 14 There are two forms of exception handling covered in this thesis: 14 15 termination, which acts as a multi-level return, 15 16 and resumption, which is a dynamic function call. 16 Note, termination exception handling is so common it is often assumed to be the only form. 17 Lesser know derivations of inter-function control flow are continuation passing in Lisp~\cite{CommonLisp}. 17 Termination handling is much more common, 18 to the extent that it is often seen 19 This seperation is uncommon because termination exception handling is so 20 much more common that it is often assumed. 21 % WHY: Mention other forms of continuation and \cite{CommonLisp} here? 22 A language's EHM is the combination of language syntax and run-time 23 components that are used to construct, raise and handle exceptions, 24 including all control flow. 18 25 19 26 Termination exception handling allows control to return to any previous … … 24 31 \end{center} 25 32 26 Resumption exception handling calls a function, but asks the functions on the27 stack what function that is.33 Resumption exception handling seaches the stack for a handler and then calls 34 it without adding or removing any other stack frames. 28 35 \todo{Add a diagram showing control flow for resumption.} 29 36 … … 35 42 most of the cost only when the error actually occurs. 36 43 37 % Overview of exceptions in Cforall.38 39 \PAB{You need section titles here. Don't take them out.}40 41 44 \section{Thesis Overview} 42 43 This thesis goes over the design and implementation of the exception handling 44 mechanism (EHM) of 45 \CFA (pernounced sea-for-all and may be written Cforall or CFA). 46 %This thesis describes the design and implementation of the \CFA EHM. 45 This work describes the design and implementation of the \CFA EHM. 47 46 The \CFA EHM implements all of the common exception features (or an 48 47 equivalent) found in most other EHMs and adds some features of its own. … … 77 76 harder to replicate in other programming languages. 78 77 79 \section{Background}80 81 78 % Talk about other programming languages. 82 79 Some existing programming languages that include EHMs/exception handling … … 84 81 exceptions which unwind the stack as part of the 85 82 Exceptions also can replace return codes and return unions. 86 In functional languages will also sometimes fold exceptions into monads.87 88 \PAB{You must demonstrate knowledge of background material here.89 It should be at least a full page.}90 91 \section{Contributions}92 83 93 84 The contributions of this work are: … … 102 93 \end{enumerate} 103 94 104 \todo{I can't figure out a good lead-in to the overview.} 105 Covering the existing \CFA features in \autoref{c:existing}. 106 Then the new features are introduce in \autoref{c:features}, explaining their 107 usage and design. 95 \todo{I can't figure out a good lead-in to the roadmap.} 96 The next section covers the existing state of exceptions. 97 The existing state of \CFA is also covered in \autoref{c:existing}. 98 The new features are introduced in \autoref{c:features}, 99 which explains their usage and design. 108 100 That is followed by the implementation of those features in 109 101 \autoref{c:implement}. 110 % Future Work \autoref{c:future} 102 The performance results are examined in \autoref{c:performance}. 103 Possibilities to extend this project are discussed in \autoref{c:future}. 104 105 \section{Background} 106 \label{s:background} 107 108 Exception handling is not a new concept, 109 with papers on the subject dating back 70s. 110 111 Their were popularised by \Cpp, 112 which added them in its first major wave of non-object-orientated features 113 in 1990. 114 % https://en.cppreference.com/w/cpp/language/history 115 116 Java was the next popular language to use exceptions. It is also the most 117 popular language with checked exceptions. 118 Checked exceptions are part of the function interface they are raised from. 119 This includes functions they propogate through, until a handler for that 120 type of exception is found. 121 This makes exception information explicit, which can improve clarity and 122 safety, but can slow down programming. 123 Some of these, such as dealing with high-order methods or an overly specified 124 throws clause, are technical. However some of the issues are much more 125 human, in that writing/updating all the exception signatures can be enough 126 of a burden people will hack the system to avoid them. 127 Including the ``catch-and-ignore" pattern where a catch block is used without 128 anything to repair or recover from the exception. 129 130 %\subsection 131 Resumption exceptions have been much less popular. 132 Although resumption has a history as old as termination's, very few 133 programming languages have implement them. 134 % http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/ 135 % CSL-79-3_Mesa_Language_Manual_Version_5.0.pdf 136 Mesa is one programming languages that did and experiance with that 137 languages is quoted as being one of the reasons resumptions were not 138 included in the \Cpp standard. 139 % https://en.wikipedia.org/wiki/Exception_handling 140 \todo{A comment about why we did include them when they are so unpopular 141 might be approprate.} 142 143 %\subsection 144 Functional languages, tend to use solutions like the return union, but some 145 exception-like constructs still appear. 146 147 For instance Haskell's built in error mechanism can make the result of any 148 expression, including function calls. Any expression that examines an 149 error value will in-turn produce an error. This continues until the main 150 function produces an error or until it is handled by one of the catch 151 functions. 152 153 %\subsection 154 More recently exceptions seem to be vanishing from newer programming 155 languages. 156 Rust and Go reduce this feature to panics. 157 Panicing is somewhere between a termination exception and a program abort. 158 Notably in Rust a panic can trigger either, a panic may unwind the stack or 159 simply kill the process. 160 % https://doc.rust-lang.org/std/panic/fn.catch_unwind.html 161 Go's panic is much more similar to a termination exception but there is 162 only a catch-all function with \code{Go}{recover()}. 163 So exceptions still are appearing, just in reduced forms. 164 165 %\subsection 166 Exception handling's most common use cases are in error handling. 167 Here are some other ways to handle errors and comparisons with exceptions. 168 \begin{itemize} 169 \item\emph{Error Codes}: 170 This pattern uses an enumeration (or just a set of fixed values) to indicate 171 that an error has occured and which error it was. 172 173 There are some issues if a function wants to return an error code and another 174 value. The main issue is that it can be easy to forget checking the error 175 code, which can lead to an error being quitely and implicitly ignored. 176 Some new languages have tools that raise warnings if the return value is 177 discarded to avoid this. 178 It also puts more code on the main execution path. 179 \item\emph{Special Return with Global Store}: 180 A function that encounters an error returns some value indicating that it 181 encountered a value but store which error occured in a fixed global location. 182 183 Perhaps the C standard @errno@ is the most famous example of this, 184 where some standard library functions will return some non-value (often a 185 NULL pointer) and set @errno@. 186 187 This avoids the multiple results issue encountered with straight error codes 188 but otherwise many of the same advantages and disadvantages. 189 It does however introduce one other major disadvantage: 190 Everything that uses that global location must agree on all possible errors. 191 \item\emph{Return Union}: 192 Replaces error codes with a tagged union. 193 Success is one tag and the errors are another. 194 It is also possible to make each possible error its own tag and carry its own 195 additional information, but the two branch format is easy to make generic 196 so that one type can be used everywhere in error handling code. 197 198 This pattern is very popular in functional or semi-functional language, 199 anything with primitive support for tagged unions (or algebraic data types). 200 % We need listing Rust/rust to format code snipits from it. 201 % Rust's \code{rust}{Result<T, E>} 202 203 The main disadvantage is again it puts code on the main execution path. 204 This is also the first technique that allows for more information about an 205 error, other than one of a fix-set of ids, to be sent. 206 They can be missed but some languages can force that they are checked. 207 It is also implicitly forced in any languages with checked union access. 208 \item\emph{Handler Functions}: 209 On error the function that produced the error calls another function to 210 handle it. 211 The handler function can be provided locally (passed in as an argument, 212 either directly as as a field of a structure/object) or globally (a global 213 variable). 214 215 C++ uses this as its fallback system if exception handling fails. 216 \snake{std::terminate_handler} and for a time \snake{std::unexpected_handler} 217 218 Handler functions work a lot like resumption exceptions. 219 The difference is they are more expencive to set up but cheaper to use, and 220 so are more suited to more fequent errors. 221 The exception being global handlers if they are rarely change as the time 222 in both cases strinks towards zero. 223 \end{itemize} 224 225 %\subsection 226 Because of their cost exceptions are rarely used for hot paths of execution. 227 There is an element of self-fulfilling prophocy here as implementation 228 techniques have been designed to make exceptions cheap to set-up at the cost 229 of making them expencive to use. 230 Still, use of exceptions for other tasks is more common in higher-level 231 scripting languages. 232 An iconic example is Python's StopIteration exception which is thrown by 233 an iterator to indicate that it is exausted. Combined with Python's heavy 234 use of the iterator based for-loop. 235 % https://docs.python.org/3/library/exceptions.html#StopIteration -
doc/theses/andrew_beach_MMath/performance.tex
r6ba6846 rb680198 4 4 \textbf{Just because of the stage of testing there are design notes for 5 5 the tests as well as commentary on them.} 6 \todo{Revisit organization of the performance chapter once tests are chosen.} 7 % What are good tests for resumption? 6 8 7 9 Performance has been of secondary importance for most of this project. 8 Instead, the goal has been to get the features working. 9 The only performance 10 requirements is to ensure the exception tests for correctness ran in a reasonable 10 Instead, the focus has been to get the features working. The only performance 11 requirements is to ensure the tests for correctness run in a reasonable 11 12 amount of time. 12 Much of the implementation is still reasonable and could be used for similar prototypes.13 Hence,14 the work still has some use.15 To get a rough idea about the \CFA implementation, tests are run on \CFA, C++ and Java, which have similar termination-handling exceptions.16 Tests are also run on \CFA and uC++, which has similar resumption-handling exceptions.17 13 18 \section{Termination Comparison} 14 %\section{Termination Comparison} 15 \section{Test Set-Up} 16 Tests will be run on \CFA, C++ and Java. 17 19 18 C++ is the most comparable language because both it and \CFA use the same 20 19 framework, libunwind. … … 24 23 there are some features it does not handle. 25 24 26 The Java comparison is an opportunity to compare a managed memory model with unmanaged, 27 to see if there are any effects related to the exception model. 25 Java is another very popular language with similar termination semantics. 26 It is implemented in a very different environment, a virtual machine with 27 garbage collection. 28 It also implements the finally clause on try blocks allowing for a direct 29 feature-to-feature comparison. 28 30 29 \subsection{Test Set-Up} 30 All tests are run inside a main loop that performs the test 31 repeatedly. This design avoids start-up or tear-down time from 31 All tests are run inside a main loop which will perform the test 32 repeatedly. This is to avoids start-up or tear-down time from 32 33 affecting the timing results. 33 A consequence is that tests cannot terminate the program, which does limit 34 how tests can be implemented. There are catch-alls to keep unhandled 34 A consequence of this is that tests cannot terminate the program, 35 which does limit how tests can be implemented. 36 There are catch-alls to keep unhandled 35 37 exceptions from terminating tests. 36 38 37 The exceptions used in th is test are always a newexception based off of39 The exceptions used in these tests will always be a exception based off of 38 40 the base exception. This requirement minimizes performance differences based 39 41 on the object model. … … 44 46 hot. 45 47 46 \subsection{Tests} 47 The following tests capture the most important aspects of exception handling and should provide 48 a reasonable guide to programmers of where EHM costs occur. 48 \section{Tests} 49 The following tests were selected to test the performance of different 50 components of the exception system. 51 The should provide a guide as to where the EHM's costs can be found. 49 52 50 53 \paragraph{Raise/Handle} … … 52 55 53 56 There are a number of factors that can effect this. 54 For \CFA this includes 55 the type of raise, 57 For \CFA this includes the type of raise, 56 58 57 59 Main loop, pass through a catch-all, call through some empty helper functions … … 65 67 This has the same set-up as the raise/handle test except the intermediate 66 68 stack frames contain either an object declaration with a destructor or a 67 @try@ statement with no handlers except and a @finally@clause.69 try statement with no handlers except for a finally clause. 68 70 69 71 \paragraph{Enter/Leave} … … 71 73 is thrown? 72 74 73 Th e test is a simple matterof entering75 This test is a simple pattern of entering 74 76 and leaving a try statement. 75 77 … … 82 84 In this case different languages approach this problem differently, either 83 85 through a re-throw or a conditional-catch. 84 Where \CFA uses its condition , other languages mustunconditionally86 Where \CFA uses its condition other languages will have to unconditionally 85 87 catch the exception then re-throw if the condition if the condition is false. 86 88 … … 90 92 % We could do a Cforall test without the catch all and a new default handler 91 93 % that does a catch all. 92 As a point of comparison ,one of the raise/handle tests (which one?) has94 As a point of comparison one of the raise/handle tests (which one?) has 93 95 same layout but never catches anything. 94 96 … … 105 107 %related to -fexceptions.) 106 108 107 108 \section{Resumption Comparison}109 109 % Some languages I left out: 110 110 % Python: Its a scripting language, different 111 111 % uC++: Not well known and should the same results as C++, except for 112 112 % resumption which should be the same. 113 114 %\section{Resumption Comparison} 113 115 \todo{Can we find a good language to compare resumptions in.}
Note: See TracChangeset
for help on using the changeset viewer.