Changeset 8e4aa05 for doc/theses/andrew_beach_MMath/future.tex

Timestamp:

Mar 4, 2021, 7:40:25 PM (5 years ago)

Author:

Thierry Delisle <tdelisle@…>

Branches:

ADT, arm-eh, ast-experimental, enum, forall-pointer-decay, jacob/cs343-translation, master, new-ast-unique-expr, pthread-emulation, qualifiedEnum

Children:

77d601f

Parents:

342af53 (diff), a5040fe (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:

• doc/theses/andrew_beach_MMath/future.tex (modified) (1 diff)

doc/theses/andrew_beach_MMath/future.tex

@@ -1 +1 @@
 \chapter{Future Work}
 
+\section{Language Improvements}
+\CFA is a developing programming language. As such, there are partially or
+unimplemented features of the language (including several broken components)
+that I had to workaround while building an exception handling system largely in
+the \CFA language (some C components).  The following are a few of these
+issues, and once implemented/fixed, how this would affect the exception system.
+\begin{itemize}
+\item
+The implementation of termination is not portable because it includes
+hand-crafted assembly statements. These sections must be ported by hand to
+support more hardware architectures, such as the ARM processor.
+\item
+Due to a type-system problem, the catch clause cannot bind the exception to a
+reference instead of a pointer. Since \CFA has a very general reference
+capability, programmers will want to use it. Once fixed, this capability should
+result in little or no change in the exception system.
+\item
+Termination handlers cannot use local control-flow transfers, \eg by @break@,
+@return@, \etc. The reason is that current code generation hoists a handler
+into a nested function for convenience (versus assemble-code generation at the
+@try@ statement). Hence, when the handler runs, its code is not in the lexical
+scope of the @try@ statement, where the local control-flow transfers are
+meaningful.
+\item
+There is no detection of colliding unwinds. It is possible for clean-up code
+run during an unwind to trigger another unwind that escapes the clean-up code
+itself; such as a termination exception caught further down the stack or a
+cancellation. There do exist ways to handle this but currently they are not
+even detected and the first unwind will simply be forgotten, often leaving
+it in a bad state.
+\item
+Also the exception system did not have a lot of time to be tried and tested.
+So just letting people use the exception system more will reveal new
+quality of life upgrades that can be made with time.
+\end{itemize}
+
 \section{Complete Virtual System}
-The virtual system should be completed. It was never supposed to be part of
-this project and so minimal work was done on it. A draft of what the complete
-system might look like was created but it was never finalized or implemented.
-A future project in \CFA would be to complete that work and to update the
-parts of the exception system that use the current version.
+The virtual system should be completed. It was not supposed to be part of this
+project, but was thrust upon it to do exception inheritance; hence, only
+minimal work was done. A draft for a complete virtual system is available but
+it is not finalized.  A future \CFA project is to complete that work and then
+update the exception system that uses the current version.
 
-For instance a full virtual system would probably allow for several
-improvements to the exception traits. Although they do currently work they
-could be made easier to use by making the virtual table type implitate in the
-trait (which would remove the need for those wrapper marcos) or allowing
-for assertions that give the layout of a virtual table for safety.
+There are several improvements to the virtual system that would improve the
+exception traits. The most important one is an assertion to check one virtual
+type is a child of another. This check precisely captures many of the
+correctness requirements.
 
-\section{Additional Throws}
-Several other kinds of throws, beyond the termination throw (\codeCFA{throw}),
-the resumption throw (\codeCFA{throwResume}) and the re-throws, were considered.
-None were as useful as the core throws but they would likely be worth
-revising.
+The full virtual system might also include other improvement like associated
+types to allow traits to refer to types not listed in their header. This
+feature allows exception traits to not refer to the virtual-table type
+explicitly, removing the need for the current interface macros.
 
-The first ones are throws for asynchronous exceptions, throwing exceptions
-from one stack to another. These act like signals allowing for communication
-between the stacks. This is usually used with resumption as it allows the
-target stack to continue execution normally after the exception has been
-handled.
+\section{Additional Raises}
+Several other kinds of exception raises were considered beyond termination
+(@throw@), resumption (@throwResume@), and reraise.
 
-This would much more coordination between the concurrency system and the
-exception system to handle. Most of the interesting design decisions around
-applying asynchronous exceptions appear to be around masking (controlling
-which exceptions may be thrown at a stack). It would likely require more of
-the virtual system and would also effect how default handlers are set.
+The first is a non-local/concurrent raise providing asynchronous exceptions,
+\ie raising an exception on another stack. This semantics acts like signals
+allowing for out-of-band communication among coroutines and threads. This kind
+of raise is often restricted to resumption to allow the target stack to
+continue execution normally after the exception has been handled. That is,
+allowing one coroutine/thread to unwind the stack of another via termination is
+bad software engineering.
 
-The other throws were designed to mimic bidirectional algebraic effects.
-Algebraic effects are used in some functional languages and allow a function
+Non-local/concurrent requires more coordination between the concurrency system
+and the exception system. Many of the interesting design decisions centre
+around masking (controlling which exceptions may be thrown at a stack). It
+would likely require more of the virtual system and would also effect how
+default handlers are set.
+
+Other raises were considered to mimic bidirectional algebraic effects.
+Algebraic effects are used in some functional languages allowing one function
 to have another function on the stack resolve an effect (which is defined with
-a function-like interface).
-These can be mimiced with resumptions and the the new throws were designed
-to try and mimic bidirectional algebraic effects, where control can go back
-and forth between the function effect caller and handler while the effect
-is underway.
+a functional-like interface).  This semantics can be mimicked with resumptions
+and new raises were discussed to mimic bidirectional algebraic-effects, where
+control can go back and forth between the function-effect caller and handler
+while the effect is underway.
 % resume-top & resume-reply
+These raises would be like the resumption raise except using different search
+patterns to find the handler.
 
-These throws would likely be just like the resumption throw except they would
-use different search patterns to find the handler to reply to.
+\section{Zero-Cost Try}
+\CFA does not have zero-cost try-statements because the compiler generates C
+code rather than assembler code \see{\VPageref{p:zero-cost}}. When the compiler
+does create its own assembly (or LLVM byte-code), then zero-cost try-statements
+are possible. The downside of zero-cost try-statements is the LSDA complexity,
+its size (program bloat), and the high cost of raising an exception.
 
-\section{Zero-Cost Exceptions}
-\CFA does not have zero-cost exceptions because it does not generate assembly
-but instead generates C code. See the implementation section. When the
-compiler does start to create its own assembly (or LLVM byte code) then
-zero-cost exceptions could be implemented.
+Alternatively, some research could be done into the simpler alternative method
+with a non-zero-cost try-statement but much lower cost exception raise. For
+example, programs are starting to use exception in the normal control path, so
+more exceptions are thrown. In these cases, the cost balance switches towards
+low-cost raise. Unfortunately, while exceptions remain exceptional, the
+libunwind model will probably remain the most effective option.
 
-Now in zero-cost exceptions the only part that is zero-cost are the try
-blocks. Some research could be done into the alternative methods for systems
-that expect a lot more exceptions to be thrown, allowing some overhead in
-entering and leaving try blocks to make throws faster. But while exceptions
-remain exceptional the libunwind model will probably remain the most effective
-option.
+Zero-cost resumptions is still an open problem. First, because libunwind does
+not support a successful-exiting stack-search without doing an unwind.
+Workarounds are possible but awkward. Ideally an extension to libunwind could
+be made, but that would either require separate maintenance or gain enough
+support to have it folded into the standard.
 
-Zero-cost resumptions have more problems to solve. First because libunwind
-does not support a successful exiting stack search without doing an unwind.
-There are several ways to hack that functionality in. Ideally an extension to
-libunwind could be made, but that would either require seperate maintenance
-or gain enough support to have it folded into the standard.
+Also new techniques to skip previously searched parts of the stack need to be
+developed to handle the recursive resume problem and support advanced algebraic
+effects.
 
-Also new techniques to skip previously searched parts of the stack will have
-to be developed.
+\section{Signal Exceptions}
+Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
+notify and signal.  Escape are termination exceptions, notify are resumption
+exceptions, leaving signal unimplemented.
 
-\section{Support for More Platforms}
-Termination is not portable because it is implemented with inline assembly.
-Those sections will have to be rewritten to support different architectures
+A signal exception allows either behaviour, \ie after an exception is handled,
+the handler has the option of returning to the raise or after the @try@
+statement. Currently, \CFA fixes the semantics of the handler return
+syntactically by the @catch@ or @catchResume@ clause.
 
-\section{Quality-of-Life Improvements}
-Finally come various improvements to the usability of \CFA. Most of these
-would just require time. Time that would not lead to interesting research so
-it has been left aside for now. A few examples are included here but there
-are more:
+Signal exception should be reexamined and possibly be supported in \CFA. A very
+direct translation is to have a new raise and catch pair, and a new statement
+(or statements) would indicate if the handler returns to the raise or continues
+where it is; but there may be other options.
 
-\begin{itemize}
-\item Allowing exception handler to bind the exception to a reference instead
-of a pointer. This should actually result in no change in behaviour so there
-is no reason not to allow it. It is however a small improvement; giving a bit
-of flexibility to the user in what style they want to use.
-\item Enabling local control flow (by \codeCFA{break}, \codeCFA{return} and
-similar statements) out of a termination handler. The current set-up makes
-this very difficult but the catch function that runs the handler after it has
-been matched could be inlined into the function's body, which would make this
-much easier. (To do the same for try blocks would probably wait for zero-cost
-exceptions, which would allow the try block to be inlined as well.)
-\item Enabling local control flow out of a resumption handler. This would be
-a weighty operation, causing a stack unwind like a termination, so there might
-be a different statement or a statement modifier to make sure the user does
-this purposefully.
+For instance, resumption could be extended to cover this use by allowing local
+control flow out of it. This approach would require an unwind as part of the
+transition as there are stack frames that have to be removed.  This approach
+means there is no notify raise, but because \CFA does not have exception
+signatures, a termination can be thrown from within any resumption handler so
+there is already a way to do mimic this in existing \CFA.
 
-However this would require the more complex system as they cannot be inlined
-into the original function as they can be run at a different place on the
-stack. So instead the unwinding will have to carry with it information on
-which one of these points to continue at and possibly also the return value
-for the function if a \codeCFA{return} statement was used.
-\end{itemize}
+% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
+% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
+% would be much easier to implement.