# source:doc/theses/andrew_beach_MMath/future.tex@e37db11

Last change on this file since e37db11 was e37db11, checked in by Andrew Beach <ajbeach@…>, 17 months ago

Andrew MMath: Two missing paragraphs in future work about special cases in virtual table generation.

• Property mode set to 100644
File size: 9.1 KB
Line
1\chapter{Future Work}
2\label{c:future}
3
4The following discussion covers both possible interesting research
5that could follow from this work as long as simple implementation
6improvements.
7
8\section{Language Improvements}
9
10\CFA is a developing programming language. As such, there are partially or
11unimplemented features (including several broken components)
12that I had to workaround while building the EHM largely in
13the \CFA language (some C components). Below are a few of these issues
14and how implementing/fixing them would affect the EHM.
15In addition there are some simple improvements that had no interesting
16research attached to them but would make using the language easier.
17\begin{itemize}
18\item
19Due to a type-system problem, the catch clause cannot bind the exception to a
20reference instead of a pointer. Since \CFA has a very general reference
21capability, programmers will want to use it. Once fixed, this capability should
22result in little or no change in the exception system but simplify usage.
23\item
24The @copy@ function in the exception virtual table is an adapter to address
25some limitations in the \CFA copy constructor. If the copy constructor is
26improved it can be used directly without the adapter.
27\item
28Termination handlers cannot use local control-flow transfers, \eg by @break@,
29@return@, \etc. The reason is that current code generation hoists a handler
30into a nested function for convenience (versus assemble-code generation at the
31try statement). Hence, when the handler runs, it can still access local
32variables in the lexical scope of the try statement. Still, it does mean
33that seemingly local control flow is not in fact local and crosses a function
34boundary.
35Making the termination handlers code within the surrounding
36function would remove this limitation.
37% Try blocks are much more difficult to do practically (requires our own
38% assembly) and resumption handlers have some theoretical complexity.
39\item
40There is no detection of colliding unwinds. It is possible for clean-up code
41run during an unwind to trigger another unwind that escapes the clean-up code
42itself; such as a termination exception caught further down the stack or a
43cancellation. There do exist ways to handle this case, but currently there is
44no detection and the first unwind will simply be forgotten, often leaving
45it in a bad state.
46\item
47Finally, the exception system has not had a lot of programmer testing.
48More time with encouraged usage will reveal new
49quality of life upgrades that can be made.
50\end{itemize}
51
52\section{Complete Virtual System}
53The virtual system should be completed. It was not supposed to be part of this
54project, but was thrust upon it to do exception inheritance; hence, only
55minimal work is done. A draft for a complete virtual system is available but
56not finalized. A future \CFA project is to complete that work and then
57update the exception system that uses the current version.
58
59There are several improvements to the virtual system that would improve the
60exception traits. The most important one is an assertion to check one virtual
61type is a child of another. This check precisely captures many of the
62current ad-hoc correctness requirements.
63
64Other features of the virtual system could also remove some of the
65special cases around exception virtual tables, such as the generation
66of the @msg@ function, could be removed.
67
68The full virtual system might also include other improvement like associated
69types to allow traits to refer to types not listed in their header. This
70feature allows exception traits to not refer to the virtual-table type
71explicitly, removing the need for the current interface macros,
72such as @EHM_IS_EXCEPTION@.
73
75Several other kinds of exception raises were considered beyond termination
76(@throw@), resumption (@throwResume@), and reraise.
77
78The first is a non-local/concurrent raise providing asynchronous exceptions,
79\ie raising an exception on another stack. This semantics acts like signals
80allowing for out-of-band communication among coroutines and threads. This kind
81of raise is often restricted to resumption to allow the target stack to
82continue execution normally after the exception has been handled. That is,
83allowing one coroutine/thread to unwind the stack of another via termination is
85
86Non-local/concurrent raise requires more
87coordination between the concurrency system
88and the exception system. Many of the interesting design decisions center
89around masking, \ie controlling which exceptions may be thrown at a stack. It
90would likely require more of the virtual system and would also effect how
91default handlers are set.
92
93Other raises were considered to mimic bidirectional algebraic effects.
94Algebraic effects are used in some functional languages allowing one function
95to have another function on the stack resolve an effect (which is defined with
96a functional-like interface).  This semantics can be mimicked with resumptions
97and new raises were discussed to mimic bidirectional algebraic-effects, where
98control can go back and forth between the function-effect caller and handler
99while the effect is underway.
100% resume-top & resume-reply
101These raises would be like the resumption raise except using different search
102patterns to find the handler.
103
104\section{Checked Exceptions}
105Checked exceptions make exceptions part of a function's type by adding an
106exception signature. An exception signature must declare all checked
107exceptions that could propagate from the function, either because they were
108raised inside the function or came from a sub-function. This improves safety
109by making sure every checked exception is either handled or consciously
110passed on.
111
112However checked exceptions were never seriously considered for this project
113because they have significant trade-offs in usability and code reuse in
114exchange for the increased safety.
115These trade-offs are most problematic when trying to pass exceptions through
116higher-order functions from the functions the user passed into the
117higher-order function. There are no well known solutions to this problem
118that were satisfactory for \CFA (which carries some of C's flexibility
119over safety design) so additional research is needed.
120
121Follow-up work might add some form of checked exceptions to \CFA,
122possibly using polymorphic exception signatures,
123a form of tunneling\cite{Zhang19} or
124checked and unchecked raises.
125
126\section{Zero-Cost Try}
127\CFA does not have zero-cost try-statements because the compiler generates C
128code rather than assembler code (see \vpageref{p:zero-cost}). When the compiler
129does create its own assembly (or LLVM byte-code), then zero-cost try-statements
130are possible. The downside of zero-cost try-statements is the LSDA complexity,
131its size (program bloat), and the high cost of raising an exception.
132
133Alternatively, some research could be done into the simpler alternative method
134with a non-zero-cost try-statement but much lower cost exception raise. For
135example, programs are starting to use exception in the normal control path, so
136more exceptions are thrown. In these cases, the cost balance switches towards
137low-cost raise. Unfortunately, while exceptions remain exceptional, the
138libunwind model will probably remain the most effective option.
139
140Zero-cost resumptions is still an open problem. First, because libunwind does
141not support a successful-exiting stack-search without doing an unwind.
142Workarounds are possible but awkward. Ideally an extension to libunwind could
143be made, but that would either require separate maintenance or gaining enough
144support to have it folded into the official library itself.
145
146Also new techniques to skip previously searched parts of the stack need to be
147developed to handle the recursive resume problem and support advanced algebraic
148effects.
149
150\section{Signal Exceptions}
151Goodenough~\cite{Goodenough75} suggests three types of exceptions: escape,
152notify and signal.  Escape are termination exceptions, notify are resumption
153exceptions, leaving signal unimplemented.
154
155A signal exception allows either behaviour, \ie after an exception is handled,
156the handler has the option of returning to the raise or after the @try@
157statement. Currently, \CFA fixes the semantics of the handler return
158syntactically by the @catch@ or @catchResume@ clause.
159
160Signal exception should be reexamined and possibly be supported in \CFA. A very
161direct translation is to have a new raise and catch pair, and a new statement
162(or statements) would indicate if the handler returns to the raise or continues
163where it is; but there may be other options.
164
165For instance, resumption could be extended to cover this use by allowing local
166control flow out of it. This approach would require an unwind as part of the
167transition as there are stack frames that have to be removed between where
168the resumption handler is installed and where it is defined.
169This approach would not require, but might benefit from, a special statement
170to leave the handler.
171Currently, mimicking this behaviour in \CFA is possible by throwing a
172termination exception inside a resumption handler.
173
174% Maybe talk about the escape; and escape CONTROL_STMT; statements or how
175% if we could choose if _Unwind_Resume proceeded to the clean-up stage this
176% would be much easier to implement.
Note: See TracBrowser for help on using the repository browser.