Changes in / [b680198:6ba6846]


Ignore:
Location:
doc/theses/andrew_beach_MMath
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • doc/theses/andrew_beach_MMath/existing.tex

    rb680198 r6ba6846  
    1 \chapter{\CFA{} Existing Features}
     1\chapter{\CFA Existing Features}
    22\label{c:existing}
    33
    … …  
    99existing C code-base allowing programmers to learn \CFA on an as-needed basis.
    1010
    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.
     11Only those \CFA features pertaining to this thesis are discussed.  Many of the
     12\CFA syntactic and semantic features used in the thesis should be fairly
     13obvious to the reader.
    1414
    1515\section{Overloading and \lstinline{extern}}
    … …  
    2929// name mangling on by default
    3030int i; // _X1ii_1
    31 extern "C" {  // disables name mangling
     31@extern "C"@ {  // disables name mangling
    3232        int j; // j
    33         extern "Cforall" {  // enables name mangling
     33        @extern "Cforall"@ {  // enables name mangling
    3434                int k; // _X1ki_1
    3535        }
    … …  
    4747Reference-types are written the same way as a pointer-type but each
    4848asterisk (@*@) is replaced with a ampersand (@&@);
    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.
     49this includes cv-qualifiers and multiple levels of reference, \eg:
     50
    5751\begin{minipage}{0,5\textwidth}
    5852With references:
    … …  
    6256int && rri = ri;
    6357rri = 3;
    64 &ri = &j;
     58&ri = &j; // reference assignment
    6559ri = 5;
    6660\end{cfa}
    … …  
    7367int ** ppi = π
    7468**ppi = 3;
    75 pi = &j;
     69pi = &j; // pointer assignment
    7670*pi = 5;
    7771\end{cfa}
    7872\end{minipage}
    7973
    80 References are intended to be used when you would use pointers but would
     74References are intended for cases where you would want to use pointers but would
    8175be dereferencing them (almost) every usage.
    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
     76In most cases a reference can just be thought of as a pointer that
     77automatically puts a dereference in front of each of its uses (per-level of
     78reference).
     79The address-of operator (@&@) acts as an escape and removes one of the
     80automatic dereference operations.
     81Mutable references may be assigned by converting them to a pointer
     82with a @&@ and then assigning a pointer to them, as in @&ri = &j;@ above.
    8483
    8584\section{Operators}
    8685
    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,
     86In general, operator names in \CFA are constructed by bracketing an operator
     87token with @?@, which indicates the position of the arguments. For example,
    9288infixed multiplication is @?*?@ while prefix dereference is @*?@.
    9389This syntax make it easy to tell the difference between prefix operations
    9490(such as @++?@) and post-fix operations (@?++@).
    9591
    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}
     92An operator name may describe any function signature (it is just a name) but
     93only certain signatures may be called in operator form.
     94\begin{cfa}
     95int ?+?( int i, int j, int k ) { return i + j + k; }
     96{
     97        sout | ?+?( 3, 4, 5 ); // no infix form
     98}
     99\end{cfa}
     100Some ``near-misses" for unary/binary operator prototypes generate warnings.
    110101
    111102Both constructors and destructors are operators, which means they are
    112103functions with special operator names rather than type names in \Cpp. The
    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.
     104special operator names may be used to call the functions explicitly (not
     105allowed in \Cpp for constructors).
     106
     107The special name for a constructor is @?{}@, where the name @{}@ comes from the
     108initialization 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,
     111passing the initialization arguments to the constructor.
     112\begin{cfa}
     113struct Structure { ... };
     114void ?{}(Structure & this) { ... }
     115{
     116        Structure a;
     117        Structure b = {};
     118}
     119void ?{}(Structure & this, char first, int num) { ... }
     120{
     121        Structure c = {'a', 2};
     122}
     123\end{cfa}
     124Both @a@ and @b@ are initialized with the first constructor,
     125while @c@ is initialized with the second.
     126Currently, there is no general way to skip initialization.
    135127
    136128% I don't like the \^{} symbol but $^\wedge$ isn't better.
    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;
     129Similarly, destructors use the special name @^?{}@ (the @^@ has no special
     130meaning).  Normally, they are implicitly called on a variable when it goes out
     131of scope but they can be called explicitly as well.
     132\begin{cfa}
     133void ^?{}(Structure & this) { ... }
     134{
     135        Structure d;
    145136} // <- implicit destructor call
    146137\end{cfa}
    147138
    148 Whenever a type is defined, \CFA will create a default zero-argument
     139Whenever a type is defined, \CFA creates a default zero-argument
    149140constructor, a copy constructor, a series of argument-per-field constructors
    150141and a destructor. All user constructors are defined after this.
    … …  
    207198void do_once(double y) { ... }
    208199int quadruple(int x) {
    209         void do_once(int & y) { y = y * 2; }
    210         do_twice(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
    211203        return x;
    212204}
    213205\end{cfa}
    214206Specifically, the complier deduces that @do_twice@'s T is an integer from the
    215 argument @x@. It then looks for the most specific definition matching the
     207argument @x@. It then looks for the most \emph{specific} definition matching the
    216208assertion, which is the nested integral @do_once@ defined within the
    217209function. The matched assertion function is then passed as a function pointer
    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.
     210to @do_twice@ and called within it.  The global definition of @do_once@ is used
     211for the second call because the float-point argument is a better match.
    223212
    224213To avoid typing long lists of assertions, constraints can be collect into
    … …  
    290279Each coroutine has a @main@ function, which takes a reference to a coroutine
    291280object and returns @void@.
    292 %[numbers=left] Why numbers on this one?
    293 \begin{cfa}
     281\begin{cfa}[numbers=left]
    294282void main(CountUp & this) {
    295283        for (unsigned int next = 0 ; true ; ++next) {

  • doc/theses/andrew_beach_MMath/features.tex

    rb680198 r6ba6846  
    22\label{c:features}
    33
    4 This chapter covers the design and user interface of the \CFA EHM
     4This chapter covers the design and user interface of the \CFA
     5EHM, % or exception system.
    56and begins with a general overview of EHMs. It is not a strict
    67definition of all EHMs nor an exhaustive list of all possible features.
    7 However it does cover the most common structure and features found in them.
    8 
    9 \section{Overview of EHMs}
     8However it does cover the most common structures and features found in them.
     9
    1010% We should cover what is an exception handling mechanism and what is an
    1111% exception before this. Probably in the introduction. Some of this could
    1212% move there.
    13 \subsection{Raise / Handle}
     13\section{Raise / Handle}
    1414An exception operation has two main parts: raise and handle.
    15 These terms are sometimes known as throw and catch but this work uses
     15These terms are sometimes also known as throw and catch but this work uses
    1616throw/catch as a particular kind of raise/handle.
    1717These are the two parts that the user writes and may
    … …  
    2424
    2525Some well known examples include the @throw@ statements of \Cpp and Java and
    26 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
     26the \code{Python}{raise} statement from Python. A raise may
     27perform some other work (such as memory management) but for the
    2828purposes of this overview that can be ignored.
    2929
    … …  
    3333
    3434A handler has three common features: the previously mentioned user code, a
    35 region of code they guard and an exception label/condition that matches
     35region of code they guard, and an exception label/condition that matches
    3636certain exceptions.
    3737Only raises inside the guarded region and raising exceptions that match the
    3838label can be handled by a given handler.
    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".
     39Different EHMs have different rules to pick a handler,
     40if multiple handlers could be used, such as ``best match" or ``first found".
    4141
    4242The @try@ statements of \Cpp, Java and Python are common examples. All three
    … …  
    4444region.
    4545
    46 \subsection{Propagation}
     46\section{Propagation}
    4747After an exception is raised comes what is usually the biggest step for the
    4848EHM: finding and setting up the handler. The propagation from raise to
    4949handler can be broken up into three different tasks: searching for a handler,
    50 matching against the handler and installing the handler.
     50matching against the handler, and installing the handler.
    5151
    5252\paragraph{Searching}
    … …  
    5555thrown as it looks for handlers that have the raise site in their guarded
    5656region.
    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.
     57This search includes handlers in the current function, as well as any in callers
     58on the stack that have the function call in their guarded region.
    5959
    6060\paragraph{Matching}
    6161Each handler found has to be matched with the raised exception. The exception
    62 label defines a condition that is used with exception and decides if
     62label defines a condition that is used with the exception to decide if
    6363there is a match or not.
    6464
    6565In languages where the first match is used, this step is intertwined with
    66 searching; a match check is preformed immediately after the search finds
     66searching: a match check is performed immediately after the search finds
    6767a possible handler.
    6868
    69 \paragraph{Installing}
     69\section{Installing}
    7070After a handler is chosen it must be made ready to run.
    7171The implementation can vary widely to fit with the rest of the
    … …  
    7474case when stack unwinding is involved.
    7575
    76 If a matching handler is not guaranteed to be found, the EHM needs a
     76If a matching handler is not guarantied to be found, the EHM needs a
    7777different course of action for the case where no handler matches.
    7878This situation only occurs with unchecked exceptions as checked exceptions
    7979(such as in Java) can make the guarantee.
    80 This unhandled action is usually very general, such as aborting the program.
     80This unhandled action can abort the program or install a very general handler.
    8181
    8282\paragraph{Hierarchy}
    8383A common way to organize exceptions is in a hierarchical structure.
    84 This pattern comes from object-orientated languages where the
     84This organization is often used in object-orientated languages where the
    8585exception hierarchy is a natural extension of the object hierarchy.
    8686
    … …  
    9090\end{center}
    9191
    92 A handler labeled with any given exception can handle exceptions of that
     92A handler labelled with any given exception can handle exceptions of that
    9393type or any child type of that exception. The root of the exception hierarchy
    9494(here \code{C}{exception}) acts as a catch-all, leaf types catch single types
    … …  
    104104% Could I cite the rational for the Python IO exception rework?
    105105
    106 \subsection{Completion}
    107 After the handler has finished, the entire exception operation has to complete
     106\paragraph{Completion}
     107After the handler has finished the entire exception operation has to complete
    108108and continue executing somewhere else. This step is usually simple,
    109109both logically and in its implementation, as the installation of the handler
    … …  
    111111
    112112The EHM can return control to many different places,
    113 the most common are after the handler definition (termination)
    114 and after the raise (resumption).
    115 
    116 \subsection{Communication}
     113the most common are after the handler definition (termination) and after the raise (resumption).
     114
     115\paragraph{Communication}
    117116For effective exception handling, additional information is often passed
    118117from the raise to the handler and back again.
    119118So far only communication of the exceptions' identity has been covered.
    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.
     119A common communication method is putting fields into the exception instance and giving the
     120handler access to them. References in the exception instance can push data back to the raise.
    124121
    125122\section{Virtuals}
    126123Virtual types and casts are not part of \CFA's EHM nor are they required for
    127124any EHM.
    128 However, it is one of the best ways to support an exception hierarchy
    129 is via a virtual hierarchy and dispatch system.
     125However, one of the best ways to support an exception hierarchy is via a virtual system
     126among exceptions and used for exception matching.
    130127
    131128Ideally, the virtual system would have been part of \CFA before the work
    132129on exception handling began, but unfortunately it was not.
    133 Hence, only the features and framework needed for the EHM were
     130Therefore, only the features and framework needed for the EHM were
    134131designed and implemented. Other features were considered to ensure that
    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.
     132the structure could accommodate other desirable features in the future but they were not
     133implemented.
     134The rest of this section discusses the implemented subset of the
     135virtual-system design.
    139136
    140137The virtual system supports multiple ``trees" of types. Each tree is
    … …  
    146143% A type's ancestors are its parent and its parent's ancestors.
    147144% The root type has no ancestors.
    148 % A type's descendants are its children and its children's descendants.
     145% A type's decedents are its children and its children's decedents.
    149146
    150147Every virtual type also has a list of virtual members. Children inherit
    … …  
    153150of object-orientated programming, and can be of any type.
    154151
     152\PAB{I do not understand these sentences. Can you add an example? $\Rightarrow$
    155153\CFA still supports virtual methods as a special case of virtual members.
    156154Function pointers that take a pointer to the virtual type are modified
    157155with each level of inheritance so that refers to the new type.
    158156This means an object can always be passed to a function in its virtual table
    159 as if it were a method.
    160 \todo{Clarify (with an example) virtual methods.}
     157as if it were a method.}
    161158
    162159Each virtual type has a unique id.
    … …  
    164161into a virtual table type. Each virtual type has a pointer to a virtual table
    165162as a hidden field.
    166 \todo{Might need a diagram for virtual structure.}
     163
     164\PAB{God forbid, maybe you need a UML diagram to relate these entities.}
    167165
    168166Up until this point the virtual system is similar to ones found in
    … …  
    175173types can begin to satisfy a trait, stop satisfying a trait or satisfy the same
    176174trait in a different way at any lexical location in 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.
     175In this sense, they are ``open" as they can change at any time. This capability means it
     176is impossible to pick a single set of functions that represent the type's
     177implementation across the program.
    180178
    181179\CFA side-steps this issue by not having a single virtual table for each
    182180type. A user can define virtual tables that are filled in at their
    183 declaration and given a name. Anywhere that name is visible, even if it is
     181declaration and given a name. Anywhere that name is visible, even if
    184182defined locally inside a function (although that means it does not have a
    185183static lifetime), it can be used.
    … …  
    188186through the object.
    189187
     188\PAB{The above explanation is very good!}
     189
    190190While much of the virtual infrastructure is created, it is currently only used
    191191internally for exception handling. The only user-level feature is the virtual
    192 cast, which is the same as the \Cpp \code{C++}{dynamic_cast}.
     192cast
    193193\label{p:VirtualCast}
    194194\begin{cfa}
    195195(virtual TYPE)EXPRESSION
    196196\end{cfa}
     197which is the same as the \Cpp \code{C++}{dynamic_cast}.
    197198Note, the syntax and semantics matches a C-cast, rather than the function-like
    198199\Cpp syntax for special casts. Both the type of @EXPRESSION@ and @TYPE@ must be
    … …  
    217218The trait is defined over two types, the exception type and the virtual table
    218219type. Each exception type should have a single virtual table type.
    219 There are no actual assertions in this trait because the trait system
    220 cannot express them yet (adding such assertions would be part of
     220There are no actual assertions in this trait because currently the trait system
     221cannot express them (adding such assertions would be part of
    221222completing the virtual system). The imaginary assertions would probably come
    222223from a trait defined by the virtual system, and state that the exception type
    223 is a virtual type, is a descendant of @exception_t@ (the base exception type)
     224is a virtual type, is a descendent of @exception_t@ (the base exception type)
    224225and note its virtual table type.
    225226
    … …  
    240241};
    241242\end{cfa}
    242 Both traits ensure a pair of types are an exception type, its virtual table
    243 type
     243Both traits ensure a pair of types are an exception type and its virtual table,
    244244and defines one of the two default handlers. The default handlers are used
    245245as fallbacks and are discussed in detail in \vref{s:ExceptionHandling}.
    … …  
    269269\section{Exception Handling}
    270270\label{s:ExceptionHandling}
    271 As stated,
    272 \CFA provides two kinds of exception handling: termination and resumption.
     271As stated, \CFA provides two kinds of exception handling: termination and resumption.
    273272These twin operations are the core of \CFA's exception handling mechanism.
    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.
     273This section covers the general patterns shared by the two operations and
     274then go on to cover the details of each individual operation.
    276275
    277276Both operations follow the same set of steps.
    278 Both start with the user preforming a raise on an exception.
     277Both start with the user performing a raise on an exception.
    279278Then the exception propagates up the stack.
    280279If a handler is found the exception is caught and the handler is run.
    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.
     280After that control returns to a point specific to the kind of exception.
     281If the search fails a default handler is run, and if it returns, control
     282continues after the raise. Note, the default handler may further change control flow rather than return.
    284283
    285284This general description covers what the two kinds have in common.
    286 Differences include how propagation is preformed, where exception continues
     285Differences include how propagation is performed, where exception continues
    287286after an exception is caught and handled and which default handler is run.
    288287
    289288\subsection{Termination}
    290289\label{s:Termination}
     290
    291291Termination handling is the familiar kind and used in most programming
    292292languages with exception handling.
    … …  
    313313
    314314The throw copies the provided exception into managed memory to ensure
    315 the exception is not destroyed if the stack is unwound.
     315the exception is not destroyed when the stack is unwound.
    316316It is the user's responsibility to ensure the original exception is cleaned
    317317up whether the stack is unwound or not. Allocating it on the stack is
    318318usually sufficient.
    319319
    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,
     320Then propagation starts the search. \CFA uses a ``first match" rule so
     321matching is performed with the copied exception as the search continues.
     322It starts from the throwing function and proceeds towards the base of the stack,
    324323from callee to caller.
    325324At each stack frame, a check is made for resumption handlers defined by the
    … …  
    335334\end{cfa}
    336335When viewed on its own, a try statement simply executes the statements
    337 in \snake{GUARDED_BLOCK} and when those are finished,
    338 the try statement finishes.
     336in \snake{GUARDED_BLOCK} and when those are finished, the try statement finishes.
    339337
    340338However, while the guarded statements are being executed, including any
    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.
     339invoked functions, all the handlers in these statements are included on the search
     340path. Hence, if a termination exception is raised, the search includes the added handlers associated with the guarded block and those further up the
     341stack from the guarded block.
    345342
    346343Exception matching checks the handler in each catch clause in the order
    347344they appear, top to bottom. If the representation of the raised exception type
    348345is the same or a descendant of @EXCEPTION_TYPE@$_i$ then @NAME@$_i$
    349 (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
     346(if provided) is bound to a pointer to the exception and the statements in
     347@HANDLER_BLOCK@$_i$ are executed.
     348If control reaches the end of the handler, the exception is
    352349freed and control continues after the try statement.
    353350
    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.
     351If no termination handler is found during the search, the default handler
     352(\defaultTerminationHandler) visible at the raise statement is called.
     353Through \CFA's trait system, the best match at the raise sight is used.
     354This function is run and is passed the copied exception. If the default
     355handler returns, control continues after the throw statement.
    359356
    360357There is a global @defaultTerminationHandler@ that is polymorphic over all
    361 termination exception types.
    362 Since it is so general a more specific handler can be
     358termination exception types. Since it is so general, a more specific handler can be
    363359defined and is used for those types, effectively overriding the handler
    364360for a particular exception type.
    … …  
    374370matched a closure is taken from up the stack and executed,
    375371after which the raising function continues executing.
    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.
     372These are most often used when a potentially repairable error occurs, some handler is found on the stack to fix it, and
     373the raising function can continue with the correction.
     374Another common usage is dynamic event analysis, \eg logging, without disrupting control flow.
     375Note, 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}.
     378You may or may not want to mention it. You can still stick with \lstinline{catch} and \lstinline{throw/catchResume} in the thesis.}
    381379
    382380A resumption raise is started with the @throwResume@ statement:
    … …  
    384382throwResume EXPRESSION;
    385383\end{cfa}
    386 \todo{Decide on a final set of keywords and use them everywhere.}
    387384It works much the same way as the termination throw.
    388385The expression must return a reference to a resumption exception,
    … …  
    390387@is_resumption_exception@ at the call site.
    391388The assertions from this trait are available to
    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.
     389the exception system, while handling the exception.
     390
     391Resumption does not need to copy the raised exception, as the stack is not unwound.
     392The exception and
     393any values on the stack remain in scope, while the resumption is handled.
     394
     395The EHM then begins propogation. The search starts from the raise in the
     396resuming function and proceeds towards the base of the stack, from callee to caller.
    401397At each stack frame, a check is made for resumption handlers defined by the
    402398@catchResume@ clauses of a @try@ statement.
    … …  
    416412kind of raise.
    417413When a try statement is executed, it simply executes the statements in the
    418 @GUARDED_BLOCK@ and then finishes.
     414@GUARDED_BLOCK@ and then returns.
    419415
    420416However, while the guarded statements are being executed, including any
    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.
     417invoked functions, all the handlers in these statements are included on the search
     418path. Hence, if a resumption exception is raised the search includes the added handlers associated with the guarded block and those further up the
     419stack from the guarded block.
    425420
    426421Exception matching checks the handler in each catch clause in the order
    … …  
    432427the raise statement that raised the handled exception.
    433428
    434 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
     429Like termination, if no resumption handler is found during the search, the default handler
     430(\defaultResumptionHandler) visible at the raise statement is called.
     431It uses the best match at the
     432raise sight according to \CFA's overloading rules. The default handler is
     433passed the exception given to the throw. When the default handler finishes
    439434execution continues after the raise statement.
    440435
    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.
     436There is a global \defaultResumptionHandler{} that is polymorphic over all
     437resumption exception types and preforms a termination throw on the exception.
     438The \defaultTerminationHandler{} can be
     439customized by introducing a new or better match as well.
    445440
    446441\subsubsection{Resumption Marking}
    447442\label{s:ResumptionMarking}
     443
    448444A key difference between resumption and termination is that resumption does
    449445not unwind the stack. A side effect that is that when a handler is matched
    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.
     446and run, its try block (the guarded statements) and every try statement
     447searched before it are still on the stack. Their existence can lead to the recursive
     448resumption problem.
    453449
    454450The recursive resumption problem is any situation where a resumption handler
    … …  
    463459\end{cfa}
    464460When this code is executed, the guarded @throwResume@ starts a
    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.
     461search and matchs the handler in the @catchResume@ clause. This
     462call is placed on the top of stack above the try-block. The second throw
     463searchs the same try block and puts call another instance of the
     464same handler on the stack leading to an infinite recursion.
    469465
    470466While this situation is trivial and easy to avoid, much more complex cycles
    471467can form with multiple handlers and different exception types.
    472468
    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.
     469To prevent all of these cases, the exception search marks the try statements it visits.
     470A try statement is marked when a match check is preformed with it and an
     471exception. The statement is unmarked when the handling of that exception
     472is completed or the search completes without finding a handler.
     473While a try statement is marked, its handlers are never matched, effectify
     474skipping over them to the next try statement.
    479475
    480476\begin{center}
    … …  
    482478\end{center}
    483479
    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.
     480These rules mirror what happens with termination.
     481When a termination throw happens in a handler, the search does not look at
     482any handlers from the original throw to the original catch because that
     483part of the stack is unwound.
     484A resumption raise in the same situation wants to search the entire stack,
     485but with marking, the search does match exceptions for try statements at equivalent sections
     486that would have been unwound by termination.
     487
     488The symmetry between resumption termination is why this pattern is picked.
     489Other patterns, such as marking just the handlers that caught the exception, also work but
     490lack the symmetry, meaning there are more rules to remember.
    497491
    498492\section{Conditional Catch}
     493
    499494Both termination and resumption handler clauses can be given an additional
    500495condition to further control which exceptions they handle:
    … …  
    509504did not match.
    510505
    511 The condition matching allows finer matching by checking
     506The condition matching allows finer matching to check
    512507more kinds of information than just the exception type.
    513508\begin{cfa}
    … …  
    524519// Can't handle a failure relating to f2 here.
    525520\end{cfa}
    526 In this example the file that experienced the IO error is used to decide
     521In this example, the file that experianced the IO error is used to decide
    527522which handler should be run, if any at all.
    528523
    … …  
    553548
    554549\subsection{Comparison with Reraising}
     550
    555551A more popular way to allow handlers to match in more detail is to reraise
    556552the exception after it has been caught, if it could not be handled here.
    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:
     553On the surface these two features seem interchangable.
     554
     555If @throw@ is used to start a termination reraise then these two statements
     556have the same behaviour:
    562557\begin{cfa}
    563558try {
    … …  
    579574}
    580575\end{cfa}
    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/
     576However, if there are further handlers after this handler only the first is
     577check. For multiple handlers on a single try block that could handle the
     578same exception, the equivalent translations to conditional catch becomes more complex, resulting is multiple nested try blocks for all possible reraises.
     579So 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.
     582A conditional catch CAN happen with the stack unwound.
     583Roy talked about this issue in Section 2.3.3 here: \newline
     584\url{http://plg.uwaterloo.ca/theses/KrischerThesis.pdf}}
     585
     586Specifically for termination handling, a
     587conditional catch happens before the stack is unwound, but a reraise happens
     588afterwards. Normally this might only cause you to loose some debug
     589information you could get from a stack trace (and that can be side stepped
     590entirely by collecting information during the unwind). But for \CFA there is
     591another issue, if the exception is not handled the default handler should be
     592run at the site of the original raise.
     593
     594There are two problems with this: the site of the original raise does not
     595exist anymore and the default handler might not exist anymore. The site is
     596always removed as part of the unwinding, often with the entirety of the
     597function it was in. The default handler could be a stack allocated nested
     598function removed during the unwind.
     599
     600This means actually trying to pretend the catch didn't happening, continuing
     601the original raise instead of starting a new one, is infeasible.
     602That is the expected behaviour for most languages and we can't replicate
     603that behaviour.
    639604
    640605\section{Finally Clauses}
    641606\label{s:FinallyClauses}
     607
    642608Finally clauses are used to preform unconditional clean-up when leaving a
    643609scope and are placed at the end of a try statement after any handler clauses:
    … …  
    652618The @FINALLY_BLOCK@ is executed when the try statement is removed from the
    653619stack, including when the @GUARDED_BLOCK@ finishes, any termination handler
    654 finishes or during an unwind.
     620finishes, or during an unwind.
    655621The only time the block is not executed is if the program is exited before
    656622the stack is unwound.
    … …  
    668634
    669635Not all languages with unwinding have finally clauses. Notably \Cpp does
    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.
     636without it as destructors with RAII serve a similar role. Although destructors and
     637finally clauses have overlapping usage cases, they have their own
     638specializations, like top-level functions and lambda functions with closures.
     639Destructors take more work if a number of unrelated, local variables without destructors or dynamically allocated variables must be passed for de-intialization.
     640Maintaining this destructor during local-block modification is a source of errors.
     641A finally clause places local de-intialization inline with direct access to all local variables.
    681642
    682643\section{Cancellation}
    … …  
    691652raise, this exception is not used in matching only to pass information about
    692653the cause of the cancellation.
    693 (This also means matching cannot fail so there is no default handler.)
     654(This restriction also means matching cannot fail so there is no default handler.)
    694655
    695656After @cancel_stack@ is called the exception is copied into the EHM's memory
    696 and the current stack is unwound.
    697 The behaviour after that depends on the kind of stack being cancelled.
     657and the current stack is
     658unwound.
     659The result of a cancellation depends on the kind of stack that is being unwound.
    698660
    699661\paragraph{Main Stack}
    … …  
    702664After the main stack is unwound there is a program-level abort.
    703665
    704 There are two reasons for these semantics.
    705 The first is that it had to do this abort.
     666There are two reasons for this semantics. The first is that it obviously had to do the abort
    706667in a sequential program as there is nothing else to notify and the simplicity
    707668of keeping the same behaviour in sequential and concurrent programs is good.
    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.
     669\PAB{I do not understand this sentence. $\Rightarrow$ Also, even in concurrent programs, there is no stack that an innate connection
     670to, so it would have be explicitly managed.}
    710671
    711672\paragraph{Thread Stack}
    … …  
    719680and an implicit join (from a destructor call). The explicit join takes the
    720681default handler (@defaultResumptionHandler@) from its calling context while
    721 the implicit join provides its own; which does a program abort if the
     682the implicit join provides its own, which does a program abort if the
    722683@ThreadCancelled@ exception cannot be handled.
    723684
    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.
     685\PAB{Communication can occur during the lifetime of a thread using shared variable and \lstinline{waitfor} statements.
     686Are 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
     687communication with other threads: start and join.}
    727688Since a thread must be running to perform a cancellation (and cannot be
    728689cancelled from another stack), the cancellation must be after start and
    729 before the join, so join is used.
     690before the join, so join is use.
    730691
    731692% TODO: Find somewhere to discuss unwind collisions.
    … …  
    734695a destructor and prevents cascading the error across multiple threads if
    735696the user is not equipped to deal with it.
    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.
     697Also you can always add an explicit join if that is the desired behaviour.
    741698
    742699\paragraph{Coroutine Stack}
    … …  
    744701satisfies the @is_coroutine@ trait.
    745702After a coroutine stack is unwound, control returns to the @resume@ function
    746 that most recently resumed it. @resume@ reports a
    747 @CoroutineCancelled@ exception, which contains a references to the cancelled
     703that most recently resumed it. The resume reports a
     704@CoroutineCancelled@ exception, which contains references to the cancelled
    748705coroutine and the exception used to cancel it.
    749706The @resume@ function also takes the \defaultResumptionHandler{} from the
    750 caller's context and passes it to the internal report.
     707caller's context and passes it to the internal cancellation.
    751708
    752709A coroutine knows of two other coroutines, its starter and its last resumer.
    … …  
    754711(in terms of coroutine state) called resume on this coroutine, so the message
    755712is 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

    rb680198 r6ba6846  
    33
    44\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.}
    85\CFA is a developing programming language. As such, there are partially or
    96unimplemented features of the language (including several broken components)
    … …  
    1411\item
    1512The implementation of termination is not portable because it includes
    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
     13hand-crafted assembly statements. These sections must be ported by hand to
    1914support more hardware architectures, such as the ARM processor.
     15\PAB{I think this is a straw-man problem because the hand-coded assembler code
     16has to be generated somewhere, and that somewhere is hand-coded.}
    2017\item
    2118Due to a type-system problem, the catch clause cannot bind the exception to a
    … …  
    3330There is no detection of colliding unwinds. It is possible for clean-up code
    3431run during an unwind to trigger another unwind that escapes the clean-up code
    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.
     32itself, \eg, a termination exception caught further down the stack or a
     33cancellation. There do exist ways to handle this issue, but currently they are not
     34even detected and the first unwind is simply dropped, often leaving
     35it in a bad state. \Cpp terminates the program in this case, and Java picks the ...
    3936\item
    4037Also the exception system did not have a lot of time to be tried and tested.
    … …  
    7269bad software engineering.
    7370
    74 Non-local/concurrent raise requires more
    75 coordination between the concurrency system
     71Non-local/concurrent raise requires more coordination between the concurrency system
    7672and the exception system. Many of the interesting design decisions centre
    7773around masking, \ie controlling which exceptions may be thrown at a stack. It
    … …  
    9894passed on.
    9995
    100 However checked exceptions were never seriously considered for this project
    101 because they have significant trade-offs in usablity and code reuse in
     96However checked exceptions were never seriously considered for this project because
     97they have significant usability and reuse trade-offs in
    10298exchange for the increased safety.
    10399These trade-offs are most problematic when trying to pass exceptions through
    … …  
    107103over safety design) so additional research is needed.
    108104
    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
     105Follow-up work might find a compromise design for checked exceptions in \CFA, possibly using
     106polymorphic exception signatures, a form of tunneling\cite{Zhang19}, or
    112107checked and unchecked raises.
    113108
    … …  
    153148For instance, resumption could be extended to cover this use by allowing local
    154149control flow out of it. This approach would require an unwind as part of the
    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.
     150transition as there are stack frames that have to be removed back to the resumption handler.  This approach
     151means no special statement is required in the handler to continue after it.
     152Currently, \CFA allows a termination exception to be thrown from within any resumption handler so
     153there is already a way to partially mimic signal exceptions.
    161154
    162155% Maybe talk about the escape; and escape CONTROL_STMT; statements or how

  • doc/theses/andrew_beach_MMath/implement.tex

    rb680198 r6ba6846  
    1717pointer to the virtual table, which is called the \emph{virtual-table pointer}.
    1818Internally, the field is called \snake{virtual_table}.
    19 The field is fixed after construction. It is always the first field in the
     19The field is fixed after construction and is the first field in the
    2020structure so that its location is always known.
    2121\todo{Talk about constructors for virtual types (after they are working).}
    2222
    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
     23The virtual-table pointer is what binds an instance of a virtual type to its virtual table. This
     24pointer is used as an identity check, and to access the
    2625virtual table and the virtual members there.
    2726
    2827\subsection{Type Id}
    2928Every virtual type has a unique id.
    30 Type ids can be compared for equality,
    31 which checks if the types reperented are the same,
     29Type ids can be compared for equality (\ie the types represented are the same)
    3230or used to access the type's type information.
    3331The type information currently is only the parent's type id or, if the
    34 type has no parent, the null pointer.
     32type has no parent, @0p@.
    3533
    3634The id's are implemented as pointers to the type's type information instance.
    3735Dereferencing the pointer gets the type information.
    38 The ancestors of a virtual type are found by traversing type ids through
     36The ancestors of a virtual type are found by traversing the type id through
    3937the type information.
    40 The information pushes the issue of creating a unique value (for
     38An id also pushes the issue of creating a unique value (for
    4139the type id) to the problem of creating a unique instance (for type
    4240information), which the linker can solve.
    4341
    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:
     42Advanced linker support is required because there is no place that appears
     43only once to attach the type information to. There should be one structure
     44definition but it is included in multiple translation units because of separate compilation. Each virtual
     45table definition should be unique but there are an arbitrary number of these,
     46so the special section prefix \texttt{.gnu.linkonce} is used.
     47With a generated unique suffix (making the entire section name unique) the linker
     48removes multiple definition ensuring only one version exists after linking.
     49Then it is just a matter of making sure there is a unique name for each type.
     50
     51These steps are done in three phases.
    5852\begin{enumerate}
    5953\item
    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
     54The first phase is to generate a new structure definition to store the type
    6455information. The layout is the same in each case, just the parent's type id,
    65 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
     56but the types are changed.
     57The structure's name is change, it is based off the virtual type's name, and
     58the type of the parent's type id.
     59If the virtual type is polymorphic, then the type information structure is
    6960polymorphic as well, with the same polymorphic arguments.
    7061\item
    71 A seperate name for instances is generated from the type's name.
    72 \item
    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.
     62The second phase is to generate an instance of the type information with a
     63almost unique name, generated by mangling the virtual type name.
     64\item
     65The third phase is implicit with \CFA's overloading scheme. \CFA mangles
     66names with type information so that all of the symbols exported to the linker
     67are unique even if in the \CFA code they are the same. Having two declarations
     68with the same name and same type is forbidden because it is impossible for
     69overload resolution to pick between them. This is the reason why a unique type is
     70generated for each virtual type.
     71Polymorphic information is included in this mangling so polymorphic
     72types have separate instances for each set of polymorphic arguments.
    8073\end{enumerate}
    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;
     74The following example shows the components for a generated virtual type.
     75\begin{cfa}
     76struct TYPE_ID_TYPE {
     77        PARENT_ID_TYPE const * parent;
    8878};
    8979
    9080__attribute__((cfa_linkonce))
    91 INFO_TYPE(TYPE) const INFO_NAME(TYPE) = {
    92         &INFO_NAME(PARENT),
     81TYPE_ID_TYPE const TYPE_ID_NAME = {
     82        &PARENT_ID_NAME,
    9383};
    9484\end{cfa}
    9585
    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.
     86\subsubsection{\lstinline{cfa_linkonce} Attribute}
    9987Another feature added to \CFA is a new attribute: \texttt{cfa\_linkonce}.
    10088This attribute is attached to an object or function definition
    10189(any global declaration with a name and a type)
    10290allowing it to be defined multiple times.
    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.
     91All matching definitions must have the link-once attribute on them and should
     92be identical.
     93This attributed prototype is placed in a header file with other
     94forward declaration.
     95
     96This technique is used for type-id instances, as there is no unique location
     97associated with a type, except for the type definition in a header.
     98The result is the unique type-id object generated by the linker.
    11399
    114100Internally, @cfa_linkonce@ is replaced with
    115101@section(".gnu.linkonce.NAME")@ where \texttt{NAME} is replaced by the
    116102mangled name of the object.
    117 Any other @section@ attributes are removed from the declaration.
     103Any other @section@ attributes are also removed from the declaration.
    118104The prefix \texttt{.gnu.linkonce} in section names is recognized by the
    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.
     105linker. If two of these sections appear with the same name, including everything
     106that comes after the special prefix, then only one is used and the other
     107discarded.
    122108
    123109\subsection{Virtual Table}
    124 \label{ss:VirtualTable}
    125110Each virtual type has a virtual table type that stores its type id and
    126111virtual members.
    … …  
    130115below.
    131116
    132 The layout always comes in three parts.
    133 \todo{Add labels to the virtual table layout figure.}
     117Figure~\ref{f:VirtualTableLayout} shows the layout is in three parts.
     118\PAB{Number the parts in the figure.}
     119\begin{enumerate}
     120\item
    134121The first section is just the type id at the head of the table. It is always
    135 there to ensure that it can be found even when the accessing code does not
    136 know which virtual type it has.
     122there to ensure that \PAB{... missing text to end this sentence}
     123\item
    137124The second section are all the virtual members of the parent, in the same
    138125order as they appear in the parent's virtual table. Note that the type may
    139 change slightly as references to the ``this" will change. This is limited to
     126change slightly as references to the @this@ change. This structure is limited to
    140127inside pointers/references and via function pointers so that the size (and
    141128hence the offsets) are the same.
     129\item
    142130The third section is similar to the second except that it is the new virtual
    143131members introduced at this level in the hierarchy.
     132\end{enumerate}
    144133
    145134\begin{figure}
    … …  
    153142prefix that has the same layout and types as its parent virtual table.
    154143This, combined with the fixed offset to the virtual table pointer, means that
    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
     144for any virtual type, it or any of its
     145descendants can be accessed through
     146the virtual table pointer.
     147From there, it is safe to check the type id to identify the exact type of the
     148underlying object, access any of the virtual members, and pass the object to
    158149any of the method-like virtual members.
    159150
    … …  
    162153the context of the declaration.
    163154
    164 The type id is always fixed; with each virtual table type having
     155The type id is always fixed with each virtual table type having
    165156exactly one possible type id.
    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.
     157The virtual members are usually filled in during type resolution. The best match for
     158a given name and type at the declaration site is used.
     159There are two exceptions to that rule: the @size@ field is the type's size
     160set using a @sizeof@ expression, and the @align@ field is the
     161type's alignment set using an @alignof@ expression.
    171162
    172163\subsubsection{Concurrency Integration}
    … …  
    177168at the definition of the main function.
    178169
    179 This is showned through code re-writing in
    180 \autoref{f:ConcurrencyTransformations}.
     170Figure~\ref{f:ConcurrencyTransformations} shows ...
     171\todo{Improve Concurrency Transformations figure.}
    181172
    182173\begin{figure}
    … …  
    215206\label{f:ConcurrencyTransformations}
    216207\end{figure}
    217 \todo{Improve Concurrency Transformations figure.}
    218208
    219209\subsection{Virtual Cast}
    … …  
    232222the cast target is passed in as @child@.
    233223
    234 For generated C code wraps both arguments and the result with type casts.
     224The generated C code wraps both arguments and the result with type casts.
    235225There is also an internal check inside the compiler to make sure that the
    236226target type is a virtual type.
    237227% It also checks for conflicting definitions.
    238228
    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.
     229The virtual cast either returns the original pointer as a new type or 0p.
     230So the function just does the parent check and returns the appropriate value.
    242231The parent check is a simple linear search of child's ancestors using the
    243232type information.
    … …  
    268257Allocating/deallocating stack space is usually an $O(1)$ operation achieved by
    269258bumping the hardware stack-pointer up or down as needed.
    270 Constructing/destructing values within a stack frame has
    271 a similar complexity but can add additional work and take longer.
     259In fact, constructing/destructing values within a stack frame is of similar complexity but often takes longer.
    272260
    273261Unwinding across multiple stack frames is more complex because that
    274262information is no longer contained within the current function.
    275 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
     263With separate compilation a function has no way of knowing what its callers
     264so it can not know how large those frames are.
     265Without altering the main code path, it is also hard to pass that work off
    278266to the caller.
    279267
    … …  
    284272stack. It is up to the programmer to ensure the snap-shot is valid when it is
    285273reset and that all required clean-up from the unwound stacks is performed.
    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,
     274This approach is fragile and forces extra work in the surrounding code.
     275
     276With respect to the extra work in the surrounding code,
    289277many languages define clean-up actions that must be taken when certain
    290278sections of the stack are removed. Such as when the storage for a variable
    291 is removed from the stack or when a try statement with a finally clause is
     279is removed from the stack or when a @try@ statement with a finally clause is
    292280(conceptually) popped from the stack.
    293 None of these should be handled by the user --- that would contradict the
     281None of these should be handled explicitly by the user --- that would contradict the
    294282intention of these features --- so they need to be handled automatically.
    295283
    … …  
    320308instruction pointer is within a region's start/end, then execution is currently
    321309executing in that region. Regions are used to mark out the scopes of objects
    322 with destructors and try blocks.
     310with destructors and @try@ blocks.
    323311
    324312% Libunwind actually does very little, it simply moves down the stack from
    … …  
    338326The attribute is used on a variable and specifies a function,
    339327in this case @clean_up@, run when the variable goes out of scope.
    340 This feature is enough to mimic destructors,
    341 but not try statements which can effect
     328This capability is enough to mimic destructors, but not @try@ statements which can effect
    342329the unwinding.
    343330
    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}.
     331To get full unwinding support, all of these components must done directly with
     332assembly and assembler directives, particularly the cfi directives
     333\snake{.cfi_Leda} and \snake{.cfi_personality}.
    347334
    348335\subsection{Personality Functions}
    … …  
    388375The @exception_class@ argument is a copy of the
    389376\code{C}{exception}'s @exception_class@ field,
    390 which is a number that identifies the exception handling mechanism
    391 that created the exception.
     377which is a number that identifies the exception handling mechanism that created
     378the \PAB{... missing text to end this sentence}
    392379
    393380The \code{C}{exception} argument is a pointer to a user
    … …  
    405392messages for special cases (some of which should never be used by the
    406393personality function) and error codes. However, unless otherwise noted, the
    407 personality function always returns @_URC_CONTINUE_UNWIND@.
     394personality function always return @_URC_CONTINUE_UNWIND@.
    408395
    409396\subsection{Raise Exception}
    410 Raising an exception is the central function of libunwind and it performs
     397Raising an exception is the central function of libunwind and it performs the
    411398two-staged unwinding.
    412399\begin{cfa}
    … …  
    498485\Cpp exceptions closely. The main complication for \CFA is that the
    499486compiler generates C code, making it very difficult to generate the assembly to
    500 form the LSDA for try blocks or destructors.
     487form the LSDA for @try@ blocks or destructors.
    501488
    502489\subsection{Memory Management}
    … …  
    513500\label{f:ExceptionLayout}
    514501\end{figure}
    515 
    516 Exceptions are stored in variable-sized blocks
    517 (see \autoref{f:ExceptionLayout}).
     502\todo*{Convert the exception layout to an actual diagram.}
     503
     504Exceptions are stored in variable-sized blocks (see Figure~\vref{f:ExceptionLayout}).
    518505The first component is a fixed-sized data structure that contains the
    519506information for libunwind and the exception system. The second component is an
    … …  
    530517high enough), which must be allocated. The previous exceptions may not be
    531518freed because the handler/catch clause has not been run.
    532 Therefore, the EHM must keep all unhandled exceptions alive
    533 while it allocates exceptions for new throws.
     519Therefore, the EHM must keep all of these exceptions alive while it allocates exceptions for new throws.
    534520
    535521\begin{figure}
    … …  
    598584exception into managed memory. After the exception is handled, the free
    599585function is used to clean up the exception and then the entire node is
    600 passed to free, returning the memory back to the heap.
     586passed to free so the memory is returned to the heap.
    601587
    602588\subsection{Try Statements and Catch Clauses}
    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
     589The @try@ statement with termination handlers is complex because it must
     590compensate for the C code-generation versus assembly-code generation from \CFA. Libunwind
    606591requires an LSDA and personality function for control to unwind across a
    607592function. The LSDA in particular is hard to mimic in generated C code.
    608593
    609594The workaround is a function called @__cfaehm_try_terminate@ in the standard
    610 library. The contents of a try block and the termination handlers are converted
     595library. The contents of a @try@ block and the termination handlers are converted
    611596into functions. These are then passed to the try terminate function and it
    612597calls them.
    613598Because this function is known and fixed (and not an arbitrary function that
    614 happens to contain a try statement), the LSDA can be generated ahead
     599happens to contain a @try@ statement), the LSDA can be generated ahead
    615600of time.
    616601
    … …  
    618603embedded assembly. This assembly code is handcrafted using C @asm@ statements
    619604and contains
    620 enough information for a single try statement the function repersents.
     605enough information for a single @try@ statement the function represents.
    621606
    622607The three functions passed to try terminate are:
    623608\begin{description}
    624 \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
     609\item[try function:] This function is the @try@ block, where all the code inside the
     610@try@ block is wrapped inside the function. It takes no parameters and has no
    626611return value. This function is called during regular execution to run the try
    627612block.
    … …  
    635620handler that matches the exception.
    636621
    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.
     622\item[handler function:] This function handles the exception, where the code inside
     623is constructed by stitching together the bodies of
     624each handler of a @try@ statement and dispatches to the selected handler.
    640625It takes a
    641626pointer to the exception and the handler's id and returns nothing. It is called
    … …  
    643628\end{description}
    644629All three functions are created with GCC nested functions. GCC nested functions
    645 can be used to create closures,
    646 in other words functions that can refer to the state of other
     630can be used to create closures, \ie functions that can refer to the state of other
    647631functions on the stack. This approach allows the functions to refer to all the
    648632variables in scope for the function containing the @try@ statement. These
    … …  
    652636Using this pattern, \CFA implements destructors with the cleanup attribute.
    653637
    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.}
     638Figure~\ref{f:TerminationTransformation} shows an example transformation for a \CFA @try@
     639statement with  @catch@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.}
    657640
    658641\begin{figure}
    … …  
    670653\hrule
    671654\medskip
    672 \todo*{Termination Transformation divider feels too strong.}
    673655
    674656\begin{cfa}
    … …  
    725707Instead of storing the data in a special area using assembly,
    726708there is just a linked list of possible handlers for each stack,
    727 with each node on the list reperenting a try statement on the stack.
     709with each list node representing a @try@ statement on the stack.
    728710
    729711The head of the list is stored in the exception context.
    730 The nodes are stored in order, with the more recent try statements closer
     712The nodes are stored in order, with the more recent @try@ statements closer
    731713to the head of the list.
    732714Instead of traversing the stack, resumption handling traverses the list.
    733 At each node, the EHM checks to see if the try statement the node repersents
     715At each node, the EHM checks to see if the @try@ statement it represents
    734716can handle the exception. If it can, then the exception is handled and
    735717the operation finishes, otherwise the search continues to the next node.
    736 If the search reaches the end of the list without finding a try statement
     718If the search reaches the end of the list without finding a @try@ statement
    737719that can handle the exception, the default handler is executed and the
    738720operation finishes.
    … …  
    742724if the exception is handled and false otherwise.
    743725
    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.}
     726For each @catchResume@ clause, the handler function:
     727\begin{itemize}
     728\item
     729checks to see if the raised exception is a descendant type of the declared
     730exception type,
     731\item
     732if it is and there is a conditional expression then it
     733runs the test,
     734\item
     735if both checks pass the handling code for the clause is run and the function returns true,
     736\item
     737otherwise it moves onto the next clause.
     738\end{itemize}
     739If this is the last @catchResume@ clause then instead of moving onto
     740the next clause the function returns false as no handler could be found.
     741
     742Figure~\ref{f:ResumptionTransformation} shows an example transformation for a \CFA @try@
     743statement with @catchResume@ clauses into corresponding C functions. \PAB{Walk the reader through the example code.}
    756744
    757745\begin{figure}
    … …  
    765753}
    766754\end{cfa}
    767 
    768 \medskip
    769 \hrule
    770 \medskip
    771 \todo*{Resumption Transformation divider feels too strong.}
    772755
    773756\begin{cfa}
    … …  
    801784
    802785% Recursive Resumption Stuff:
    803 \autoref{f:ResumptionMarking} shows search skipping
    804 (see \vpageref{s:ResumptionMarking}), which ignores parts of
     786Figure~\ref{f:ResumptionMarking} shows the search skipping (see \vpageref{s:ResumptionMarking}), which ignores parts of
    805787the stack
    806788already examined, is accomplished by updating the front of the list as the
    … …  
    808790is updated to the next node of the current node. After the search is complete,
    809791successful or not, the head of the list is reset.
    810 % No paragraph?
    811792This mechanism means the current handler and every handler that has already
    812793been checked are not on the list while a handler is run. If a resumption is
    813794thrown during the handling of another resumption, the active handlers and all
    814795the other handler checked up to this point are not checked again.
    815 % No paragraph?
    816796This structure also supports new handlers added while the resumption is being
    817797handled. These are added to the front of the list, pointing back along the
    818 stack --- the first one points over all the checked handlers ---
    819 and the ordering is maintained.
     798stack -- the first one points over all the checked handlers -- and the ordering
     799is maintained.
     800\PAB{Maybe number the figure and use the numbers in the description to help the reader follow.}
    820801
    821802\begin{figure}
    … …  
    823804\caption{Resumption Marking}
    824805\label{f:ResumptionMarking}
    825 \todo*{Label Resumption Marking to aid clarity.}
     806\todo*{Convert Resumption Marking into a line figure.}
    826807\end{figure}
    827808
    828809\label{p:zero-cost}
    829 Finally, the resumption implementation has a cost for entering/exiting a try
    830 statement with @catchResume@ clauses, whereas a try statement with @catch@
     810Finally, the resumption implementation has a cost for entering/exiting a @try@
     811statement with @catchResume@ clauses, whereas a @try@ statement with @catch@
    831812clauses has zero-cost entry/exit. While resumption does not need the stack
    832813unwinding and cleanup provided by libunwind, it could use the search phase to
    … …  
    847828around the context of the associated @try@ statement.
    848829
    849 The rest is handled by GCC. The try block and all handlers are inside this
     830The rest is handled by GCC. The @try@ block and all handlers are inside this
    850831block. At completion, control exits the block and the empty object is cleaned
    851832up, which runs the function that contains the finally code.
    … …  
    859840
    860841The first step of cancellation is to find the cancelled stack and its type:
    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.
     842coroutine or thread. Fortunately, the thread library stores the main thread
     843pointer and the current thread pointer, and every thread stores a pointer to
     844its coroutine and the coroutine it is currently executing.
    866845If the current thread's main and current coroutines are the same then the
    867846current stack is a thread stack, otherwise it is 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.
     847Note, the runtime considers a thread as a coroutine with an associated user-level thread;
     848hence, 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.
    870854
    871855However, if the threading library is not linked, the sequential execution is on
    … …  
    877861passed to the forced-unwind function. The general pattern of all three stop
    878862functions is the same: continue unwinding until the end of stack and
    879 then preform the appropriate transfer.
     863then perform the appropriate transfer.
    880864
    881865For main stack cancellation, the transfer is just a program abort.
    … …  
    888872cancelled exception. It is then resumed as a regular exception with the default
    889873handler coming from the context of the resumption call.
     874This semantics allows a cancellation to cascade through an arbitrary set of resumed
     875coroutines back to the thread's coroutine, performing cleanup along the way.
    890876
    891877For thread cancellation, the exception is stored on the thread's main stack and
    … …  
    897883null (as it is for the auto-generated joins on destructor call), the default is
    898884used, which is a program abort.
     885This semantics allows a cancellation to cascade through an arbitrary set of joining
     886threads back to the program's main, performing cleanup along the way.
    899887%; which gives the required handling on implicate join.

  • doc/theses/andrew_beach_MMath/intro.tex

    rb680198 r6ba6846  
    11\chapter{Introduction}
    22
    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.
     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.}
    117
    12 % Now take a step back and explain what exceptions are generally.
    13 Exception handling provides dynamic inter-function control flow.
     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).
     12Exception handling provides alternative dynamic inter-function control flow.
    1413There are two forms of exception handling covered in this thesis:
    1514termination, which acts as a multi-level return,
    1615and resumption, which is a dynamic function call.
    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.
     16Note, termination exception handling is so common it is often assumed to be the only form.
     17Lesser know derivations of inter-function control flow are continuation passing in Lisp~\cite{CommonLisp}.
    2518
    2619Termination exception handling allows control to return to any previous
    … …  
    3124\end{center}
    3225
    33 Resumption exception handling seaches the stack for a handler and then calls
    34 it without adding or removing any other stack frames.
     26Resumption exception handling calls a function, but asks the functions on the
     27stack what function that is.
    3528\todo{Add a diagram showing control flow for resumption.}
    3629
    … …  
    4235most of the cost only when the error actually occurs.
    4336
     37% Overview of exceptions in Cforall.
     38
     39\PAB{You need section titles here. Don't take them out.}
     40
    4441\section{Thesis Overview}
    45 This work describes the design and implementation of the \CFA EHM.
     42
     43This thesis goes over the design and implementation of the exception handling
     44mechanism (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.
    4647The \CFA EHM implements all of the common exception features (or an
    4748equivalent) found in most other EHMs and adds some features of its own.
    … …  
    7677harder to replicate in other programming languages.
    7778
     79\section{Background}
     80
    7881% Talk about other programming languages.
    7982Some existing programming languages that include EHMs/exception handling
    … …  
    8184exceptions which unwind the stack as part of the
    8285Exceptions also can replace return codes and return unions.
     86In functional languages will also sometimes fold exceptions into monads.
     87
     88\PAB{You must demonstrate knowledge of background material here.
     89It should be at least a full page.}
     90
     91\section{Contributions}
    8392
    8493The contributions of this work are:
    … …  
    93102\end{enumerate}
    94103
    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.
     104\todo{I can't figure out a good lead-in to the overview.}
     105Covering the existing \CFA features in \autoref{c:existing}.
     106Then the new features are introduce in \autoref{c:features}, explaining their
     107usage and design.
    100108That is followed by the implementation of those features in
    101109\autoref{c:implement}.
    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
     110% Future Work \autoref{c:future}

  • doc/theses/andrew_beach_MMath/performance.tex

    rb680198 r6ba6846  
    44\textbf{Just because of the stage of testing there are design notes for
    55the 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?
    86
    97Performance has been of secondary importance for most of this project.
    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
     8Instead, the goal has been to get the features working.
     9The only performance
     10requirements is to ensure the exception tests for correctness ran in a reasonable
    1211amount of time.
     12Much of the implementation is still reasonable and could be used for similar prototypes.
     13Hence,
     14the work still has some use.
     15To get a rough idea about the \CFA implementation, tests are run on \CFA, C++ and Java, which have similar termination-handling exceptions.
     16Tests are also run on \CFA and uC++, which has similar resumption-handling exceptions.
    1317
    14 %\section{Termination Comparison}
    15 \section{Test Set-Up}
    16 Tests will be run on \CFA, C++ and Java.
    17 
     18\section{Termination Comparison}
    1819C++ is the most comparable language because both it and \CFA use the same
    1920framework, libunwind.
    … …  
    2324there are some features it does not handle.
    2425
    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.
     26The Java comparison is an opportunity to compare a managed memory model with unmanaged,
     27to see if there are any effects related to the exception model.
    3028
    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
     29\subsection{Test Set-Up}
     30All tests are run inside a main loop that performs the test
     31repeatedly. This design avoids start-up or tear-down time from
    3332affecting the timing results.
    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
     33A consequence is that tests cannot terminate the program, which does limit
     34how tests can be implemented. There are catch-alls to keep unhandled
    3735exceptions from terminating tests.
    3836
    39 The exceptions used in these tests will always be a exception based off of
     37The exceptions used in this test are always a new exception based off of
    4038the base exception. This requirement minimizes performance differences based
    4139on the object model.
    … …  
    4644hot.
    4745
    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.
     46\subsection{Tests}
     47The following tests capture the most important aspects of exception handling and should provide
     48a reasonable guide to programmers of where EHM costs occur.
    5249
    5350\paragraph{Raise/Handle}
    … …  
    5552
    5653There are a number of factors that can effect this.
    57 For \CFA this includes the type of raise,
     54For \CFA this includes
     55the type of raise,
    5856
    5957Main loop, pass through a catch-all, call through some empty helper functions
    … …  
    6765This has the same set-up as the raise/handle test except the intermediate
    6866stack frames contain either an object declaration with a destructor or a
    69 try statement with no handlers except for a finally clause.
     67@try@ statement with no handlers except and a @finally@ clause.
    7068
    7169\paragraph{Enter/Leave}
    … …  
    7371is thrown?
    7472
    75 This test is a simple pattern of entering
     73The test is a simple matter of entering
    7674and leaving a try statement.
    7775
    … …  
    8482In this case different languages approach this problem differently, either
    8583through a re-throw or a conditional-catch.
    86 Where \CFA uses its condition other languages will have to unconditionally
     84Where \CFA uses its condition, other languages must unconditionally
    8785catch the exception then re-throw if the condition if the condition is false.
    8886
    … …  
    9290% We could do a Cforall test without the catch all and a new default handler
    9391% that does a catch all.
    94 As a point of comparison one of the raise/handle tests (which one?) has
     92As a point of comparison, one of the raise/handle tests (which one?) has
    9593same layout but never catches anything.
    9694
    … …  
    107105%related to -fexceptions.)
    108106
     107
     108\section{Resumption Comparison}
    109109% Some languages I left out:
    110110% Python: Its a scripting language, different
    111111% uC++: Not well known and should the same results as C++, except for
    112112%   resumption which should be the same.
    113 
    114 %\section{Resumption Comparison}
    115113\todo{Can we find a good language to compare resumptions in.}
Note: See TracChangeset for help on using the changeset viewer.