X-Git-Url: http://git.hcoop.net/bpt/emacs.git/blobdiff_plain/e6fd457e010c2ec034a331335530d817852cc11c..611e8a48541d27e24e89facadae4822f6c39285d:/doc/lispref/internals.texi diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi index c9758f8704..14ebde46b0 100644 --- a/doc/lispref/internals.texi +++ b/doc/lispref/internals.texi @@ -1,9 +1,9 @@ @c -*-texinfo-*- @c This is part of the GNU Emacs Lisp Reference Manual. -@c Copyright (C) 1990-1993, 1998-1999, 2001-2012 Free Software Foundation, Inc. +@c Copyright (C) 1990-1993, 1998-1999, 2001-2013 Free Software +@c Foundation, Inc. @c See the file elisp.texi for copying conditions. -@node GNU Emacs Internals, Standard Errors, Tips, Top -@comment node-name, next, previous, up +@node GNU Emacs Internals @appendix GNU Emacs Internals This chapter describes how the runnable Emacs executable is dumped with @@ -216,10 +216,23 @@ You should not change this flag in a running Emacs. (such as by loading a library), that data is placed in normal storage. If normal storage runs low, then Emacs asks the operating system to allocate more memory. Different types of Lisp objects, such as -symbols, cons cells, markers, etc., are segregated in distinct blocks -in memory. (Vectors, long strings, buffers and certain other editing -types, which are fairly large, are allocated in individual blocks, one -per object, while small strings are packed into blocks of 8k bytes.) +symbols, cons cells, small vectors, markers, etc., are segregated in +distinct blocks in memory. (Large vectors, long strings, buffers and +certain other editing types, which are fairly large, are allocated in +individual blocks, one per object; small strings are packed into blocks +of 8k bytes, and small vectors are packed into blocks of 4k bytes). + +@cindex vector-like objects, storage +@cindex storage of vector-like Lisp objects + Beyond the basic vector, a lot of objects like window, buffer, and +frame are managed as if they were vectors. The corresponding C data +structures include the @code{struct vectorlike_header} field whose +@code{next} field points to the next object in the chain: +@code{header.next.buffer} points to the next buffer (which could be +a killed buffer), and @code{header.next.vector} points to the next +vector in a free list. If a vector is small (smaller than or equal to +@code{VBLOCK_BYTES_MAX} bytes, see @file{alloc.c}), then +@code{header.next.nbytes} contains the vector size in bytes. @cindex garbage collection It is quite common to use some storage for a while, then release it @@ -244,8 +257,12 @@ might as well be reused, since no one will miss them. The second The sweep phase puts unused cons cells onto a @dfn{free list} for future allocation; likewise for symbols and markers. It compacts the accessible strings so they occupy fewer 8k blocks; then it frees the -other 8k blocks. Vectors, buffers, windows, and other large objects are -individually allocated and freed using @code{malloc} and @code{free}. +other 8k blocks. Unreachable vectors from vector blocks are coalesced +to create largest possible free areas; if a free area spans a complete +4k block, that block is freed. Otherwise, the free area is recorded +in a free list array, where each entry corresponds to a free list +of areas of the same size. Large vectors, buffers, and other large +objects are allocated and freed individually. @cindex CL note---allocate more storage @quotation @@ -354,7 +371,7 @@ itself; the latter is only allocated when the string is created.) If there was overflow in pure space (@pxref{Pure Storage}), @code{garbage-collect} returns @code{nil}, because a real garbage -collection can not be done in this situation. +collection cannot be done. @end deffn @defopt garbage-collection-messages @@ -471,12 +488,12 @@ in this Emacs session. @defvar string-chars-consed The total number of string characters that have been allocated so far -in this Emacs session. +in this session. @end defvar @defvar misc-objects-consed The total number of miscellaneous objects that have been allocated so -far in this Emacs session. These include markers and overlays, plus +far in this session. These include markers and overlays, plus certain objects not visible to users. @end defvar @@ -495,7 +512,7 @@ Emacs session. @cindex primitive function internals @cindex writing Emacs primitives - Lisp primitives are Lisp functions implemented in C. The details of + Lisp primitives are Lisp functions implemented in C@. The details of interfacing the C function so that Lisp can call it are handled by a few C macros. The only way to really understand how to write new C code is to read the source, but we can explain some things here. @@ -580,8 +597,8 @@ there is a fixed maximum. Alternatively, it can be @code{UNEVALLED}, indicating a special form that receives unevaluated arguments, or @code{MANY}, indicating an unlimited number of evaluated arguments (the equivalent of @code{&rest}). Both @code{UNEVALLED} and @code{MANY} are -macros. If @var{max} is a number, it may not be less than @var{min} and -it may not be greater than eight. +macros. If @var{max} is a number, it must be more than @var{min} but +less than 8. @item interactive This is an interactive specification, a string such as might be used as @@ -777,7 +794,7 @@ DEFUN ("coordinates-in-window-p", Fcoordinates_in_window_p, @end smallexample Note that C code cannot call functions by name unless they are defined -in C. The way to call a function written in Lisp is to use +in C@. The way to call a function written in Lisp is to use @code{Ffuncall}, which embodies the Lisp function @code{funcall}. Since the Lisp function @code{funcall} accepts an unlimited number of arguments, in C it takes two: the number of Lisp-level arguments, and a @@ -834,7 +851,7 @@ explicitly using a suitable predicate (@pxref{Type Predicates}). @cindex buffer internals Two structures (see @file{buffer.h}) are used to represent buffers -in C. The @code{buffer_text} structure contains fields describing the +in C@. The @code{buffer_text} structure contains fields describing the text of a buffer; the @code{buffer} structure holds other fields. In the case of indirect buffers, two or more @code{buffer} structures reference the same @code{buffer_text} structure. @@ -1126,7 +1143,7 @@ These fields contain the window's leftmost child and its topmost child respectively. @code{hchild} is used if the window is subdivided horizontally by child windows, and @code{vchild} if it is subdivided vertically. In a live window, only one of @code{hchild}, @code{vchild}, -and @code{buffer} (q.v.) is non-@code{nil}. +and @code{buffer} (q.v.@:) is non-@code{nil}. @item next @itemx prev @@ -1364,7 +1381,7 @@ needs to be reported, either by running the sentinel or by inserting a message in the process buffer. @item pty_flag -Non-@code{nil} if communication with the subprocess uses a @acronym{PTY}; +Non-@code{nil} if communication with the subprocess uses a pty; @code{nil} if it uses a pipe. @item infd