Ignore:
Timestamp:
Jan 29, 2021, 8:23:52 AM (9 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
arm-eh, jacob/cs343-translation, master, new-ast-unique-expr
Children:
5669d0b
Parents:
4dcd5ea
Message:

complete first proofread of Andrew's thesis

File:
1 edited

Legend:

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

    r4dcd5ea r7eb6eb5  
    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 generalized to support
     13more hardware architectures, \eg 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\end{itemize}
     27
    328\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.
     29The virtual system should be completed. It was not supposed to be part of this
     30project, but was thrust upon it to do exception inheritance; hence, only
     31minimal work was done. A draft for a complete virtual system is available but
     32it is not finalized.  A future \CFA project is to complete that work and then
     33update the exception system that uses the current version.
    934
    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.
     35There are several improvements to the virtual system that would improve the
     36exception traits. The most important one is an assertion to check one virtual
     37type is a child of another. This check precisely captures many of the
     38correctness requirements.
    1439
    1540The 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.
     41types to allow traits to refer to types not listed in their header. This
     42feature allows exception traits to not refer to the virtual-table type
     43explicitly, removing the need for the current interface macros.
    2044
    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.
     45\section{Additional Raises}
     46Several other kinds of exception raises were considered beyond termination
     47(@throw@), resumption (@throwResume@), and reraise.
    2648
    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.
     49The first is a non-local/concurrent raise providing asynchronous exceptions,
     50\ie raising an exception on another stack. This semantics acts like signals
     51allowing for out-of-band communication among coroutines and threads. This kind
     52of raise is often restricted to resumption to allow the target stack to
     53continue execution normally after the exception has been handled. That is,
     54allowing one coroutine/thread to unwind the stack of another via termination is
     55bad software engineering.
    3256
    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.
     57Non-local/concurrent requires more coordination between the concurrency system
     58and the exception system. Many of the interesting design decisions centre
     59around masking (controlling which exceptions may be thrown at a stack). It
     60would likely require more of the virtual system and would also effect how
     61default handlers are set.
    3862
    39 The other throws were designed to mimic bidirectional algebraic effects.
    40 Algebraic effects are used in some functional languages and allow a function
     63Other raises were considered to mimic bidirectional algebraic effects.
     64Algebraic effects are used in some functional languages allowing one function
    4165to 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.
     66a functional-like interface).  This semantics can be mimicked with resumptions
     67and new raises were discussed to mimic bidirectional algebraic-effects, where
     68control can go back and forth between the function-effect caller and handler
     69while the effect is underway.
    4770% resume-top & resume-reply
     71These raises would be like the resumption raise except using different search
     72patterns to find the handler.
    4873
    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.
     74\section{Zero-Cost Try}
     75\CFA does not have zero-cost try-statements because the compiler generates C
     76code rather than assembler code \see{\VPageref{p:zero-cost}}. When the compiler
     77does create its own assembly (or LLVM byte-code), then zero-cost try-statements
     78are possible. The downside of zero-cost try-statements is the LSDA complexity,
     79its size (program bloat), and the high cost of raising an exception.
    5180
    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.
     81Alternatively, some research could be done into the simpler alternative method
     82with a non-zero-cost try-statement but much lower cost exception raise. For
     83example, programs are starting to use exception in the normal control path, so
     84more exceptions are thrown. In these cases, the cost balance switches towards
     85low-cost raise. Unfortunately, while exceptions remain exceptional, the
     86libunwind model will probably remain the most effective option.
    5787
    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.
     88Zero-cost resumptions is still an open problem. First, because libunwind does
     89not support a successful-exiting stack-search without doing an unwind.
     90Workarounds are possible but awkward. Ideally an extension to libunwind could
     91be made, but that would either require separate maintenance or gain enough
     92support to have it folded into the standard.
    6493
    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.
     94Also new techniques to skip previously searched parts of the stack need to be
     95developed to handle the recursive resume problem and support advanced algebraic
     96effects.
    7497
    7598\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.
     99Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
     100notify and signal.  Escape are termination exceptions, notify are resumption
     101exceptions, leaving signal unimplemented.
    80102
    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.
     103A signal exception allows either behaviour, \ie after an exception is handled,
     104the handler has the option of returning to the raise or after the @try@
     105statement. Currently, \CFA fixes the semantics of the handler return
     106syntactically by the @catch@ or @catchResume@ clause.
    84107
    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.
     108Signal exception should be reexamined and possibly be supported in \CFA. A very
     109direct translation is to have a new raise and catch pair, and a new statement
     110(or statements) would indicate if the handler returns to the raise or continues
     111where it is; but there may be other options.
    89112
    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.
     113For instance, resumption could be extended to cover this use by allowing local
     114control flow out of it. This approach would require an unwind as part of the
     115transition as there are stack frames that have to be removed.  This approach
     116means there is no notify raise, but because \CFA does not have exception
     117signatures, a termination can be thrown from within any resumption handler so
     118there is already a way to do mimic this in existing \CFA.
    96119
    97120% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
    98121% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
    99122% 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.