From 85ba8812a3800797573847893367cf4515d10f0f Mon Sep 17 00:00:00 2001 From: kostis Date: Fri, 8 Jun 2007 22:18:12 +0000 Subject: [PATCH] Final changes. git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1900 b08c6af1-5177-4d33-ba66-4b1c6b8b522a --- docs/index/iclp07.tex | 56 +++++++++++++++++++++---------------------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/docs/index/iclp07.tex b/docs/index/iclp07.tex index 4c444ffe5..79557ec34 100644 --- a/docs/index/iclp07.tex +++ b/docs/index/iclp07.tex @@ -116,8 +116,8 @@ percent up to orders of magnitude. Given these results, we see very little reason for Prolog systems not to incorporate some form of dynamic indexing based on actual demand. In fact, we see - demand-driven indexing as the first step towards effective runtime - optimization of Prolog programs. + demand-driven indexing as only the first step towards effective + runtime optimization of Prolog programs. \end{abstract} @@ -167,8 +167,8 @@ incorporate some form of indexing based on actual demand from queries. In fact, we see \JITI as only the first step towards effective runtime optimization of Prolog programs. -\Paragraph{Organization} -%----------------------- +\Paragraph{Organization.} +%------------------------ After commenting on the state of the art and related work concerning indexing in Prolog systems (Sect.~\ref{sec:related}) we briefly review indexing in the WAM (Sect.~\ref{sec:prelims}). We then present \JITI @@ -205,7 +205,7 @@ user-friendly nor guarantees good performance results. % Trees, tries and unification factoring: Recognizing the need for better indexing, researchers have proposed -more flexible index mechanisms for Prolog. For example, Hickey and +more flexible indexing mechanisms for Prolog. For example, Hickey and Mudambi proposed \emph{switching trees}~\cite{HickeyMudambi@JLP-89}, which rely on the presence of mode information. Similar proposals were put forward by Van Roy, Demoen and Willems who investigated indexing @@ -240,7 +240,7 @@ discipline from the programmer (e.g., that applications use the module system religiously and never bypass it). As a result, most Prolog systems currently do not provide the type of indexing that applications require. Even in systems like Ciao~\cite{Ciao@SCP-05}, -which do come with built-in static analysis and more or less force +which do come with a built-in static analyzer and more or less force such a discipline on the programmer, mode information is not used for multi-argument indexing. @@ -279,8 +279,8 @@ value of the register. The \switchONconstant and \switchONstructure instructions implement this dispatching: typically with a \fail instruction when the bucket is empty, with a \jump instruction for only one clause, with a sequential scan when the number of clauses is -small, and with a hash lookup when the number of clauses exceeds a -threshold. For this reason the \switchONconstant and +small, and with a hash table lookup when the number of clauses exceeds +a threshold. For this reason the \switchONconstant and \switchONstructure instructions take as arguments the hash table \instr{T} and the number of clauses \instr{N} the table contains. In each bucket of this hash table and also in the bucket for the variable @@ -546,9 +546,9 @@ atom \code{p} throughout.} Then we can avoid generating \jitiONconstant instructions for them. Also, suppose we know that some arguments are most likely than others to be used in the \code{in} mode. Then we can simply place the \jitiONconstant instructions for -them \emph{before} the instructions for other arguments. This is -possible since all indexing instructions take the argument register -number as an argument; their order does not matter. +them before the instructions for other arguments. This is possible +since all indexing instructions take the argument register number as +an argument; their order does not matter. \subsection{From any argument indexing to multi-argument indexing} %----------------------------------------------------------------- @@ -746,16 +746,16 @@ Each non-leaf node contains a sequence of byte code instructions with groups of the form \mbox{$\langle I_1, \ldots, I_m, T_1, \ldots, T_l \rangle, 0 \leq m \leq k, 1 \leq l \leq n$} where each of the $I$ instructions, if any, is either a \switchSTAR or a \jitiSTAR -instruction and the $T$ instructions are either a sequence of -\TryRetryTrust instructions (if $l > 1$) or a \jump instruction (if -\mbox{$l = 1$}). Step~2.2 dynamically constructs an index table $\cal -T$ whose buckets are the newly created interior nodes in the tree. -Each bucket associated with a single clause contains a \jump to the -label of that clause. Each bucket associated with many clauses starts -with the $I$ instructions which are yet to be visited and continues -with a \TryRetryTrust chain pointing to the clauses. When the index -construction is done, the instruction mutates to a \switchSTAR WAM -instruction. +instruction and each of the $T$ instructions either forms a sequence +of \TryRetryTrust instructions (if $l > 1$) or is a \jump instruction +(if \mbox{$l = 1$}). Step~2.2 dynamically constructs an index table +$\cal T$ whose buckets are the newly created interior nodes in the +tree. Each bucket associated with a single clause contains a \jump to +the label of that clause. Each bucket associated with many clauses +starts with the $I$ instructions which are yet to be visited and +continues with a \TryRetryTrust chain pointing to the clauses. When +the index construction is done, the instruction mutates to a +\switchSTAR WAM instruction. %------------------------------------------------------------------------- \begin{Algorithm}[t] \caption{Actions of the abstract machine with \JITI} @@ -863,7 +863,7 @@ is easy to write. At the cost of increased implementation complexity, this step can of course take into account other information that may exist in the body of the clause (e.g., type tests such as \code{var(X)}, \code{atom(X)}, aliasing constraints such as \code{X = -Y}, numeric constraints such as \code{X > 0}, etc). +Y}, numeric constraints such as \code{X > 0}, etc.). A reasonable concern for \JITI is increased memory consumption. In our experience, this does not seem to be a problem in practice since most @@ -875,10 +875,10 @@ predicate separately. For example, the \jitiSTAR instructions can either become inactive when this limit is reached, or better yet we can recover the space of some tables. To do so, we can employ any standard recycling algorithm (e.g., LRU) and reclaim the memory of -index tables no longer in use. This is easy to do by reverting the -corresponding \switchSTAR instructions back to \jitiSTAR instructions. -If the indices are demanded again at a time when memory is available, -they can simply be regenerated. +index tables that are no longer in use. This is easy to do by +reverting the corresponding \switchSTAR instructions back to \jitiSTAR +instructions. If the indices are demanded again at a time when memory +is available, they can simply be regenerated. \section{Demand-Driven Indexing of Dynamic Predicates} \label{sec:dynamic} @@ -915,7 +915,7 @@ variable. Under LU semantics, calls to dynamic predicates execute in a ``snapshot'' of the corresponding predicate. Each call sees the clauses that existed at the time when the call was made, even if some -of the clauses were later deleted or new clauses were asserted. If +of the clauses were later retracted or new clauses were asserted. If several calls are alive in the stack, several snapshots will be alive at the same time. The standard solution to this problem is to use time stamps to tell which clauses are \emph{live} for which calls. @@ -929,7 +929,7 @@ table thus is killed in several steps: \item Recursively \emph{kill} every child of the current table; if a table is killed so are its children. \item Wait until the table is not in use, that is, it is not pointed - to by anywhere. + to from anywhere. \item Walk the table and release any references it may hold. \item Physically recover space. \end{enumerate}