|
|
1
2
|
\section{Introduction}
|
|
|
3
4
5
6
|
All programmers must deal with uncertainty about runtime environments. For
example, the most appropriate algorithm for a given task may depend on inputs
that are unknown when the function is written, and its performance may depend
on device-specific features that are impossible for the developer to
|
|
|
7
|
anticipate. In other cases, real-world testing may be required to choose
|
|
|
8
9
10
11
12
13
14
15
16
17
18
19
|
between several approaches, which has led to the popularity of split testing.
Uncertainty is especially problematic for mobile app programmers. Specific
device features, such as accurate GPS location, may or may not be available.
Networks come and go and their properties change: from fast and free Wifi
links to slower metered mobile data connections. Energy may be plentiful or
scarce, depending on the device's battery capacity and the user's energy
consumption and charging patterns. These constantly fluctuating exogenous
conditions make writing effective mobile apps particularly challenging.
Today programmers are forced to anticipate these changing conditions at
development time and implement the required adaptation themselves.
|
|
|
20
21
|
Figure~\ref{fig-example-if} shows an example of an Android app attempting to
adapt to the device's battery level by establishing regular- and low-battery
|
|
|
22
|
code paths, with the latter attempting to save energy---possibly by utilizing
|
|
|
23
24
25
26
27
28
29
30
|
a slower but more energy-efficient algorithm, computing an approximate
result, or deferring the computation.
Unfortunately, this approach has several serious weaknesses. The most
important is perhaps the least obvious: it is unclear that the different code
paths achieve the desired result. There may be no differences between the
alternatives (neither conserves energy), the alternative designed to conserve
energy may actually consume more due to bugs or incorrect assumptions, or the
|
|
|
31
32
|
outcome may depend on other factors not considered by the programmer, such as
the type of network the device is currently using.
|
|
|
33
|
|
|
|
34
35
|
In addition, attempts at pre-deployment adaptation frequently produce
arbitrary decision thresholds. Even if the two code paths in
|
|
|
36
|
Figure~\ref{fig-example-if} achieve the desired result, it is unclear what
|
|
|
37
38
39
|
battery level threshold should trigger the energy-saving path, whether a
single threshold will work for all users, and whether the threshold should
depend on other factors such as how frequently the app is used.
|
|
|
40
41
42
|
\begin{figure}[t]
\begin{minted}[fontsize=\footnotesize]{java}
|
|
|
43
|
if (plugged == false && batteryLevel < 10) {
|
|
|
44
|
// Try to save energy
|
|
|
45
|
} else {
|
|
|
46
|
// Don't try to save energy
|
|
|
47
48
49
|
}
\end{minted}
|
|
|
50
|
\vspace*{-0.2in}
|
|
|
51
|
|
|
|
52
53
|
\caption{\small\textbf{Typical Error-Prone Energy Adaptation.} The threshold is
arbitrary and the attempt to conserve energy may succeed only at certain times,
|
|
|
54
|
only for certain users, only on certain devices, or never.}
|
|
|
55
|
|
|
|
56
|
\label{fig-example-if}
|
|
|
57
|
|
|
|
58
|
\vspace*{-0.2in}
|
|
|
59
|
|
|
|
60
61
62
|
\end{figure}
Finally, the current approach to adaptation fails to support post-deployment
|
|
|
63
|
testing. While it is possible to enable flexibility, runtime adaptation, and
|
|
|
64
65
66
67
68
69
70
71
72
73
74
75
|
split testing using the languages currently used to program mobile systems,
these tasks require writing large amounts of error-prone boilerplate code
that retrieves settings from remote servers and adjusts values at runtime.
The root of the problem is that \textbf{today's languages force programmers
to be certain at a moment when they cannot be: at development time.} While
this problem is endemic to existing programming languages, when developing
mobile apps it is magnified by the amount of variation developers must
confront. Our solution is simple: (1) provide developers with a way to
express \textit{structured uncertainty}, and (2) use the resulting
flexibility to enable a large array of downstream tools for resolving
uncertainty by choosing from the alternatives provided by the developer.
|
|
|
76
77
78
79
80
|
\begin{figure}[t]
\begin{minted}[fontsize=\footnotesize]{java}
maybe {
|
|
|
81
|
// Try to save energy (Alternative 1)
|
|
|
82
|
} or {
|
|
|
83
|
// Don't to save energy (Alternative 2)
|
|
|
84
85
|
}
\end{minted}
|
|
|
86
|
|
|
|
87
|
\vspace*{-0.2in}
|
|
|
88
|
|
|
|
89
90
91
|
\caption{\small\textbf{Example \texttt{maybe} Statement.} The programmer
provides multiple alternatives. The system determines how to choose between
them.}
|
|
|
92
|
|
|
|
93
94
|
\label{fig-example-maybe}
|
|
|
95
|
\vspace*{-0.2in}
|
|
|
96
|
|
|
|
97
98
|
\end{figure}
|
|
|
99
100
101
102
103
104
105
106
107
108
109
110
111
|
\sloppypar{In this paper, we present a novel a language construct for
expressing structured uncertainty: the \texttt{maybe} statement. Unlike
previous approaches to adaptation that relied on language support,
\texttt{maybe} does not encourage programmers to provide more information
about their app to allow the compiler to improve performance or guarantee
correctness. Rather, \texttt{maybe} allows the programmer to express and
structure uncertainty by providing two or more different
\textit{alternatives} implementing multiple approaches to runtime adaptation.
Together, multiple alternatives can produce the same energy-performance or
energy-accuracy tradeoffs described previously. Conceptually, \texttt{maybe}
extends the process of compilation and optimization to include
post-deployment testing while also enabling flexible adaptation that may
produce per-user, per-device, or time-varying decisions.}
|
|
|
112
|
|
|
|
113
|
Figure~\ref{fig-example-maybe} shows how our earlier example can be easily
|
|
|
114
115
116
|
rewritten using a \texttt{maybe} statement. Unlike the previous example,
\texttt{maybe} does not rely on the developer to implement a decision process
or correctly predict the effects of each alternative. Instead, the
|
|
|
117
118
|
\texttt{maybe} system makes runtime choices about which alternative to use by
measuring the tradeoffs produced by each alternative and (in this case)
|
|
|
119
120
121
122
123
|
activating an energy-saving alternative when appropriate. When they are
unsure what to do, all developers have to do is provide alternatives; the
\texttt{maybe} system does the rest. \texttt{maybe} allows developers to
respond to uncertainty with flexibility, which is used to enable
testing-driven adaptation.
|
|
|
124
|
|
|
|
125
126
|
The rest of our paper is structured as follows. We begin by providing a more
complete description of the \texttt{maybe} statement in
|
|
|
127
|
Section~\ref{sec-maybe}. Section~\ref{sec-certainty} describes several
|
|
|
128
129
130
131
132
|
techniques for transforming development-time uncertainty into runtime
certainty. We continue by describing several example use cases in
Section~\ref{sec-usage}, discussing the implications of the \texttt{maybe}
statement in Section~\ref{sec-discussion}, and presenting related work in
Section~\ref{sec-related}. We conclude in Section~\ref{sec-conclusion}.
|
