diff options
Diffstat (limited to 'docs/storage-mgt')
| -rw-r--r-- | docs/storage-mgt/ldv.tex | 18 | ||||
| -rw-r--r-- | docs/storage-mgt/rp.tex | 38 | ||||
| -rw-r--r-- | docs/storage-mgt/sm.tex | 6 |
3 files changed, 31 insertions, 31 deletions
diff --git a/docs/storage-mgt/ldv.tex b/docs/storage-mgt/ldv.tex index ab2c8b9532..9084ae1ea4 100644 --- a/docs/storage-mgt/ldv.tex +++ b/docs/storage-mgt/ldv.tex @@ -100,7 +100,7 @@ all events associated with any closures and update necessary information. All events associated with closures are handled by one of the three macros defined -in @includes/StgLdv.h@: @LDV_recordCreate()@, @LDV_recordUse()@, and +in @rts/include/StgLdv.h@: @LDV_recordCreate()@, @LDV_recordUse()@, and @LDV_recordDead()@. \begin{itemize} @@ -145,10 +145,10 @@ typedef struct { \end{code} For instance, the LDV word of a closure @c@ can now be accessed with @c->header.prof.hp.ldvw@ (or by @LDVW(c)@ where @LDVW()@ is a macro in -@includes/StgLdvProf.h@). +@rts/include/StgLdvProf.h@). An LDV word is divided into three fields, whose position is specified -by three constants in @includes/StgLdvProf.h@: +by three constants in @rts/include/StgLdvProf.h@: \begin{itemize} \item{@LDV_STATE_MASK@} corresponds to the state flag. \item{@LDV_CREATE_MASK@} corresponds to the creation time. @@ -163,7 +163,7 @@ The creation time field and the most recent use time field can be set only by th macros @LDV_recordCreate()@ and @LDV_recordUse()@. @LDV_recordCreate()@ must be called whenever a new dynamic closure is created, and this is handily accomplished by rewriting the macro @SET_PROF_HDR()@ -(in @includes/ClosureMacros.h@) (we do not need to change @SET_STATIC_PROF_HDR()@ +(in @rts/include/ClosureMacros.h@) (we do not need to change @SET_STATIC_PROF_HDR()@ because static closures are not involved in LDVU profiling at all): \begin{code} @@ -388,7 +388,7 @@ There are four cases in which a closure is destroyed: \begin{enumerate} \item A closure is overwritten with a blackhole: - @UPD_BH_UPDATABLE()@ in @includes/StgMacros.h@, + @UPD_BH_UPDATABLE()@ in @rts/include/StgMacros.h@, @threadLazyBlackHole()@ and @threadSqueezeStack()@ in @GC.c@, the entry code for @BLACKHOLE@ closures in @StgMiscClosures.hc@ (a @BLACKHOLE@ closure is changed into a @BLACKHOLE_BQ@ closure). @@ -500,7 +500,7 @@ size, we invoke @LDV_recordDead_FILL_SLOP_DYNAMIC()@ only from: \item @threadLazyBlackHole()@ and @threadSqueezeStack()@ in @GC.c@ (for lazy blackholing), \item @UPD_BH_UPDATABLE()@ in -@includes/StgMacros.h@ (for eager blackholing, which isn't the +@rts/include/StgMacros.h@ (for eager blackholing, which isn't the default), \item @updateWithIndirection()@ and @updateWithPermIndirection()@ in @Storage.h@.\footnote{Actually slop words created in @@ -538,7 +538,7 @@ and no assumptions made upon LDVU profiling hold any longer. In order to yield correct LDVU profiling results, we must make sure that @LDV_recordUse()@ be called on a closure whenever it is used; otherwise, most of closures would be reported to be in the void phase. -@includes/StgLdvProf.h@ provides an entry macro @LDV_ENTER@ which +@rts/include/StgLdvProf.h@ provides an entry macro @LDV_ENTER@ which expands to @LDV_recordUse()@. The compiler arranges to invoke @LDV_ENTER@ in the entry code for every dynamic closure it generates code for (constructors, thunks and functions). We also have to add @@ -629,10 +629,10 @@ are almost the same, though. This section gives a summary of changes made to the GHC in implementing LDVU profiling. -Only three files (@includes/StgLdvProf.h@, @LdvProfile.c@, and +Only three files (@rts/include/StgLdvProf.h@, @LdvProfile.c@, and @LdvProfile.h@) are new, and all others exist in the GHC. -@\includes@ directory: +@\rts\include@ directory: \begin{description} \item[StgLdvProf.h] defines type @LdvGenInfo@, constants, and macros related diff --git a/docs/storage-mgt/rp.tex b/docs/storage-mgt/rp.tex index ced5c0cd4f..c0b7b5c904 100644 --- a/docs/storage-mgt/rp.tex +++ b/docs/storage-mgt/rp.tex @@ -212,21 +212,21 @@ directive as well unless otherwise mentioned.} \subsection{Adding a new field to Haskell closures} We want to add a retainer set field of type @retainerSet@ to every -closure, so we create a new file @includes/StgRetainerProf.h@ where +closure, so we create a new file @rts/include/StgRetainerProf.h@ where we define the type @retainerSet@. The actual definition of @retainerSet@ will be given later. \begin{code} -/* includes/StgRetainerProf.h */ +/* rts/include/StgRetainerProf.h */ typedef ... retainerSet; \end{code} We make type @retainerSet@ to be publicly available by including -@includes/StgRetainerProf.h@ itself to @includes/Stg.h@ (not wrapped +@rts/include/StgRetainerProf.h@ itself to @rts/include/Stg.h@ (not wrapped by @PROFILING@). \begin{code} -/* includes/Stg.h */ +/* rts/include/Stg.h */ #include "StgRetainerProf.h" \end{code} @@ -254,14 +254,14 @@ of certain types of closures and their layout. When building the runtime system, the @gcc@ compiler correctly figures out the size of every structure on its own. However, -GHC simply reads @includes/Constants.h@ to determine the size of +GHC simply reads @rts/include/Constants.h@ to determine the size of closures assumed by the runtime system. Thus, we must change the constants used by the GHC itself (as opposed to -the runtime system). They are all found in @includes/Constants.h@. +the runtime system). They are all found in @rts/include/Constants.h@. We increase each of them by 1 to reflect the retainer set field which is one word long: \begin{code} -/* includes/Constants.h */ +/* rts/include/Constants.h */ #define PROF_HDR_SIZE 2 #define SCC_UF_SIZE 5 #define SCC_SEQ_FRAME_SIZE 4 @@ -269,7 +269,7 @@ word long: @PROF_HDR_SIZE@ denotes the size of the structure @StgProfHeader@, which is now two words long. @SCC_UF_SIZE@ and @SCC_SEQ_FRAME_SIZE@ denote the size of the structures -@StgUpdateFrame@ and @StgSeqFrame@ (in @includes/Closures.h@) in +@StgUpdateFrame@ and @StgSeqFrame@ (in @rts/include/Closures.h@) in words. Now we must rebuild the GHC so that, when executed, the code generated by @@ -404,10 +404,10 @@ Finally we may need to initialize the retainer set field of an update frame (stack closure) when it is pushed onto the stack for the first time. For instance, if we want to initialize the retainer set field of update frames to a null pointer, we can rewrite the macro @PUSH_STD_CCCS()@ -(in @includes/Updates.h@) as follows: +(in @rts/include/Updates.h@) as follows: \begin{code} -/* includes/Updates.h */ +/* rts/include/Updates.h */ #define PUSH_STD_CCCS(frame) \ (frame->header.prof.ccs = CCCS, frame->header.prof.rs = NULL) \end{code} @@ -418,10 +418,10 @@ Hence, the above modification is entirely unnecessary. Also, update frames are the only exception to the standard way of creating stack closures: all the other types of stack closures with a retainer set field are eventually initialized by -the macro @SET\_HDR()@ (in @includes/ClosureMacros.h@), which in turn +the macro @SET\_HDR()@ (in @rts/include/ClosureMacros.h@), which in turn invokes @SET\_PROF\_HDR()@. This is not the case for update frames. -Compare @PUSH\_UPD\_FRAME()@ (in @includes/Updates.h@) and -@PUSH\_SEQ\_FRAME()@ (in @includes/StgMacros.h@) for clarification. +Compare @PUSH\_UPD\_FRAME()@ (in @rts/include/Updates.h@) and +@PUSH\_SEQ\_FRAME()@ (in @rts/include/StgMacros.h@) for clarification. \section{Retainer Sets} @@ -439,7 +439,7 @@ implementation. The function @R()@ in Figure~\ref{fig-retaineralgorithm} returns the identity of a retainer. In order to implement it, we need a type for retainer identity. -The type @retainer@ (in @includes/StgRetainerProf.h@) is introduced for +The type @retainer@ (in @rts/include/StgRetainerProf.h@) is introduced for this purpose. There are various ways of defining the type @retainer@. @@ -470,7 +470,7 @@ retainer getRetainerFrom(StgClosure *c) { return c->header.prof.ccs; } \subsection{Retainer sets and the cost function} A retainer set is stored in the structure @retainerSet@ -(in @includes/StgRetainerProf.h@): +(in @rts/include/StgRetainerProf.h@): \begin{code} typedef struct _retainerSet { @@ -721,7 +721,7 @@ In addition to the thread closures, weak pointers are also considered as roots; they may not be reachable from any thread closure yet are still being in used. A weak pointer has three pointer fields: @key@, @value@, and -@finalizer@ (see the structure @StgWeak@ in @includes/Closures.h@). +@finalizer@ (see the structure @StgWeak@ in @rts/include/Closures.h@). It turns out that these pointers may not be valid all the time: at a certain point during execution, for instance, the pointer @key@ may point to a dead closure. @@ -875,7 +875,7 @@ A retainer profiling scheme specifies \emph{what} retainer profiling yields (as opposed to \emph{how} retainer profiling computes the retainer set for every live object). It is determined primarily by the meaning of retainer identity, -that is, the type @retainer@ (in @includes/StgRetainerProf.h@). +that is, the type @retainer@ (in @rts/include/StgRetainerProf.h@). The function @getRetainerFrom()@ must be defined according to the definition of the type @retainer@. @@ -1032,10 +1032,10 @@ execution of retainer profiling. This section gives a summary of changes made to the GHC in implementing retainer profiling. -Only three files (@includes/StgRetainerProf.h@, @RetainerProfile.c@, and +Only three files (@rts/include/StgRetainerProf.h@, @RetainerProfile.c@, and @RetainerProfile.h@) are new, and all others exist in the GHC. -@\includes@ directory: +@\rts\include@ directory: \begin{description} \item[StgRetainerProf.h] defines types @retainer@ and @retainerSet@. diff --git a/docs/storage-mgt/sm.tex b/docs/storage-mgt/sm.tex index 4a52d61f5b..28941a5e73 100644 --- a/docs/storage-mgt/sm.tex +++ b/docs/storage-mgt/sm.tex @@ -620,7 +620,7 @@ objects whose contents can be updated and hence may contain pointers to younger generations. Every object in this linked list is a dynamic object residing in the heap and has a structure compatible with @StgMutClosure@. -The structure @StgMutClosure@ (@includes/Closures.h@) has a field +The structure @StgMutClosure@ (@rts/include/Closures.h@) has a field @mut_link@ (called a mutable link field) of type @StgMutClosure *@, which points to the next object in this linked list. The end mark of this linked list is a pointer to a statically allocated object @@ -655,14 +655,14 @@ contain static objects (as opposed to dynamic objects residing in the heap) in its list @mut_once_list@. This happens when a static thunk, also known as a \emph{constant applicative form} (CAF), is entered. When a CAF (corresponding to closure type @THUNK_STATIC@, defined -in @includes/ClosureTypes.h@) is entered, +in @rts/include/ClosureTypes.h@) is entered, it is first put in the list @mut_once_list@ of the oldest generation and then overwritten with an appropriate static indirection object (corresponding to closure type @IND_STATIC@).\footnote{Actually a static indirection object does not have a @mut\_link@ field. We use its @static\_link@ field as a substitute for @mut\_link@. See the structure @StgIndStatic@ in @include/Closures.h@.}\footnote{For -details of this operation, see the macro @UPD\_CAF()@ in @includes/Updates.h@} +details of this operation, see the macro @UPD\_CAF()@ in @rts/include/Updates.h@} If the CAF is dynamically loaded (e.g., in an interactive environment), it is instead put in a separate linked list @caf_list@ (declared in @Storage.c@). |