Ignore:
Timestamp:
Feb 12, 2021, 12:27:38 PM (8 months ago)
Author:
Thierry Delisle <tdelisle@…>
Branches:
arm-eh, jacob/cs343-translation, master, new-ast-unique-expr
Children:
eb24cec0
Parents:
da3963a (diff), 52f6250 (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/theses/andrew_beach_MMath/future.tex

    rda3963a r565acf59  
    11\chapter{Future Work}
    22
     3\section{Language Improvements}
     4\CFA is a developing programming language. As such, there are partially or
     5unimplemented features of the language (including several broken components)
     6that I had to workaround while building an exception handling system largely in
     7the \CFA language (some C components).  The following are a few of these
     8issues, and once implemented/fixed, how this would affect the exception system.
     9\begin{itemize}
     10\item
     11The implementation of termination is not portable because it includes
     12hand-crafted assembly statements. These sections must be ported by hand to
     13support more hardware architectures, such as the ARM processor.
     14\item
     15Due to a type-system problem, the catch clause cannot bind the exception to a
     16reference instead of a pointer. Since \CFA has a very general reference
     17capability, programmers will want to use it. Once fixed, this capability should
     18result in little or no change in the exception system.
     19\item
     20Termination handlers cannot use local control-flow transfers, \eg by @break@,
     21@return@, \etc. The reason is that current code generation hoists a handler
     22into a nested function for convenience (versus assemble-code generation at the
     23@try@ statement). Hence, when the handler runs, its code is not in the lexical
     24scope of the @try@ statement, where the local control-flow transfers are
     25meaningful.
     26\item
     27There is no detection of colliding unwinds. It is possible for clean-up code
     28run during an unwind to trigger another unwind that escapes the clean-up code
     29itself; such as a termination exception caught further down the stack or a
     30cancellation. There do exist ways to handle this but currently they are not
     31even detected and the first unwind will simply be forgotten, often leaving
     32it in a bad state.
     33\item
     34Also the exception system did not have a lot of time to be tried and tested.
     35So just letting people use the exception system more will reveal new
     36quality of life upgrades that can be made with time.
     37\end{itemize}
     38
    339\section{Complete Virtual System}
    4 The virtual system should be completed. It was never supposed to be part of
    5 this project and so minimal work was done on it. A draft of what the complete
    6 system might look like was created but it was never finalized or implemented.
    7 A future project in \CFA would be to complete that work and to update the
    8 parts of the exception system that use the current version.
     40The virtual system should be completed. It was not supposed to be part of this
     41project, but was thrust upon it to do exception inheritance; hence, only
     42minimal work was done. A draft for a complete virtual system is available but
     43it is not finalized.  A future \CFA project is to complete that work and then
     44update the exception system that uses the current version.
    945
    10 There are several improvements to the virtual system that would improve
    11 the exception traits. The biggest one is an assertion that checks that one
    12 virtual type is a child of another virtual type. This would capture many of
    13 the requirements much more precisely.
     46There are several improvements to the virtual system that would improve the
     47exception traits. The most important one is an assertion to check one virtual
     48type is a child of another. This check precisely captures many of the
     49correctness requirements.
    1450
    1551The full virtual system might also include other improvement like associated
    16 types. This is a proposed feature that would allow traits to refer to types
    17 not listed in their header. This would allow the exception traits to not
    18 refer to the virtual table type explicatly which would remove the need for
    19 the interface macros.
     52types to allow traits to refer to types not listed in their header. This
     53feature allows exception traits to not refer to the virtual-table type
     54explicitly, removing the need for the current interface macros.
    2055
    21 \section{Additional Throws}
    22 Several other kinds of throws, beyond the termination throw (@throw@),
    23 the resumption throw (@throwResume@) and the re-throws, were considered.
    24 None were as useful as the core throws but they would likely be worth
    25 revising.
     56\section{Additional Raises}
     57Several other kinds of exception raises were considered beyond termination
     58(@throw@), resumption (@throwResume@), and reraise.
    2659
    27 The first ones are throws for asynchronous exceptions, throwing exceptions
    28 from one stack to another. These act like signals allowing for communication
    29 between the stacks. This is usually used with resumption as it allows the
    30 target stack to continue execution normally after the exception has been
    31 handled.
     60The first is a non-local/concurrent raise providing asynchronous exceptions,
     61\ie raising an exception on another stack. This semantics acts like signals
     62allowing for out-of-band communication among coroutines and threads. This kind
     63of raise is often restricted to resumption to allow the target stack to
     64continue execution normally after the exception has been handled. That is,
     65allowing one coroutine/thread to unwind the stack of another via termination is
     66bad software engineering.
    3267
    33 This would much more coordination between the concurrency system and the
    34 exception system to handle. Most of the interesting design decisions around
    35 applying asynchronous exceptions appear to be around masking (controlling
    36 which exceptions may be thrown at a stack). It would likely require more of
    37 the virtual system and would also effect how default handlers are set.
     68Non-local/concurrent requires more coordination between the concurrency system
     69and the exception system. Many of the interesting design decisions centre
     70around masking (controlling which exceptions may be thrown at a stack). It
     71would likely require more of the virtual system and would also effect how
     72default handlers are set.
    3873
    39 The other throws were designed to mimic bidirectional algebraic effects.
    40 Algebraic effects are used in some functional languages and allow a function
     74Other raises were considered to mimic bidirectional algebraic effects.
     75Algebraic effects are used in some functional languages allowing one function
    4176to have another function on the stack resolve an effect (which is defined with
    42 a function-like interface).
    43 These can be mimiced with resumptions and the the new throws were designed
    44 to try and mimic bidirectional algebraic effects, where control can go back
    45 and forth between the function effect caller and handler while the effect
    46 is underway.
     77a functional-like interface).  This semantics can be mimicked with resumptions
     78and new raises were discussed to mimic bidirectional algebraic-effects, where
     79control can go back and forth between the function-effect caller and handler
     80while the effect is underway.
    4781% resume-top & resume-reply
     82These raises would be like the resumption raise except using different search
     83patterns to find the handler.
    4884
    49 These throws would likely be just like the resumption throw except they would
    50 use different search patterns to find the handler to reply to.
     85\section{Zero-Cost Try}
     86\CFA does not have zero-cost try-statements because the compiler generates C
     87code rather than assembler code \see{\VPageref{p:zero-cost}}. When the compiler
     88does create its own assembly (or LLVM byte-code), then zero-cost try-statements
     89are possible. The downside of zero-cost try-statements is the LSDA complexity,
     90its size (program bloat), and the high cost of raising an exception.
    5191
    52 \section{Zero-Cost Exceptions}
    53 \CFA does not have zero-cost exceptions because it does not generate assembly
    54 but instead generates C code. See the implementation section. When the
    55 compiler does start to create its own assembly (or LLVM byte code) then
    56 zero-cost exceptions could be implemented.
     92Alternatively, some research could be done into the simpler alternative method
     93with a non-zero-cost try-statement but much lower cost exception raise. For
     94example, programs are starting to use exception in the normal control path, so
     95more exceptions are thrown. In these cases, the cost balance switches towards
     96low-cost raise. Unfortunately, while exceptions remain exceptional, the
     97libunwind model will probably remain the most effective option.
    5798
    58 Now in zero-cost exceptions the only part that is zero-cost are the try
    59 blocks. Some research could be done into the alternative methods for systems
    60 that expect a lot more exceptions to be thrown, allowing some overhead in
    61 entering and leaving try blocks to make throws faster. But while exceptions
    62 remain exceptional the libunwind model will probably remain the most effective
    63 option.
     99Zero-cost resumptions is still an open problem. First, because libunwind does
     100not support a successful-exiting stack-search without doing an unwind.
     101Workarounds are possible but awkward. Ideally an extension to libunwind could
     102be made, but that would either require separate maintenance or gain enough
     103support to have it folded into the standard.
    64104
    65 Zero-cost resumptions have more problems to solve. First because libunwind
    66 does not support a successful exiting stack search without doing an unwind.
    67 There are several ways to hack that functionality in. Ideally an extension to
    68 libunwind could be made, but that would either require seperate maintenance
    69 or gain enough support to have it folded into the standard.
    70 
    71 Also new techniques to skip previously searched parts of the stack will have
    72 to be developed. The recursive resume problem still remains and ideally the
    73 same pattern of ignoring sections of the stack.
     105Also new techniques to skip previously searched parts of the stack need to be
     106developed to handle the recursive resume problem and support advanced algebraic
     107effects.
    74108
    75109\section{Signal Exceptions}
    76 Exception Handling: Issues and a Proposed Notation suggests there are three
    77 types of exceptions: escape, notify and signal.
    78 Escape exceptions are our termination exceptions, notify exceptions are
    79 resumption exceptions and that leaves signal exception unimplemented.
     110Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
     111notify and signal.  Escape are termination exceptions, notify are resumption
     112exceptions, leaving signal unimplemented.
    80113
    81 Signal exceptions allow either behaviour, that is after the exception is
    82 handled control can either return to the throw or from where the handler is
    83 defined.
     114A signal exception allows either behaviour, \ie after an exception is handled,
     115the handler has the option of returning to the raise or after the @try@
     116statement. Currently, \CFA fixes the semantics of the handler return
     117syntactically by the @catch@ or @catchResume@ clause.
    84118
    85 The design should be rexamined and be updated for \CFA. A very direct
    86 translation would perhaps have a new throw and catch pair and a statement
    87 (or statements) could be used to decide if the handler returns to the throw
    88 or continues where it is, but there are other options.
     119Signal exception should be reexamined and possibly be supported in \CFA. A very
     120direct translation is to have a new raise and catch pair, and a new statement
     121(or statements) would indicate if the handler returns to the raise or continues
     122where it is; but there may be other options.
    89123
    90 For instance resumption could be extended to cover this use by allowing
    91 local control flow out of it. This would require an unwind as part of the
    92 transition as there are stack frames that have to be removed.
    93 This would mean there is no notify like throw but because \CFA does not have
    94 exception signatures a termination can be thrown from any resumption handler
    95 already so there are already ways one could try to do this in existing \CFA.
     124For instance, resumption could be extended to cover this use by allowing local
     125control flow out of it. This approach would require an unwind as part of the
     126transition as there are stack frames that have to be removed.  This approach
     127means there is no notify raise, but because \CFA does not have exception
     128signatures, a termination can be thrown from within any resumption handler so
     129there is already a way to do mimic this in existing \CFA.
    96130
    97131% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
    98132% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
    99133% would be much easier to implement.
    100 
    101 \section{Language Improvements}
    102 There is also a lot of work that are not follow ups to this work in terms of
    103 research, some have no interesting research to be done at all, but would
    104 improve \CFA as a programming language. The full list of these would
    105 naturally be quite extensive but here are a few examples that involve
    106 exceptions:
    107 
    108 \begin{itemize}
    109 \item The implementation of termination is not portable because it includes
    110 some assembly statements. These sections will have to be re-written to so
    111 \CFA has full support on more machines.
    112 \item Allowing exception handler to bind the exception to a reference instead
    113 of a pointer. This should actually result in no change in behaviour so there
    114 is no reason not to allow it. It is however a small improvement; giving a bit
    115 of flexibility to the user in what style they want to use.
    116 \item Enabling local control flow (by @break@, @return@ and
    117 similar statements) out of a termination handler. The current set-up makes
    118 this very difficult but the catch function that runs the handler after it has
    119 been matched could be inlined into the function's body, which would make this
    120 much easier. (To do the same for try blocks would probably wait for zero-cost
    121 exceptions, which would allow the try block to be inlined as well.)
    122 \end{itemize}
Note: See TracChangeset for help on using the changeset viewer.