* doc/lispref/variables.texi (Lexical Binding): Fix typo.

[bpt/emacs.git] / doc / lispref / internals.texi

diff --git a/doc/lispref/internals.texi b/doc/lispref/internals.texi
index 5d4a9c6..14ebde4 100644 (file)
--- a/doc/lispref/internals.texi
+++ b/doc/lispref/internals.texi
@@ -1,6 +1,7 @@
 @c -*-texinfo-*-
 @c This is part of the GNU Emacs Lisp Reference Manual.
 @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
 @appendix GNU Emacs Internals
 @c See the file elisp.texi for copying conditions.
 @node GNU Emacs Internals
 @appendix GNU Emacs Internals


@@ -215,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
 (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
 
 @cindex garbage collection
   It is quite common to use some storage for a while, then release it


@@ -243,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
   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
 
 @cindex CL note---allocate more storage
 @quotation


@@ -494,7 +512,7 @@ Emacs session.
 @cindex primitive function internals
 @cindex writing Emacs primitives
 
 @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.
 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.


@@ -776,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
 @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
 @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


@@ -833,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
 @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.
 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.


@@ -1125,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},
 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
 
 @item next
 @itemx prev


@@ -1363,7 +1381,7 @@ needs to be reported, either by running the sentinel or by inserting a
 message in the process buffer.
 
 @item pty_flag
 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
 @code{nil} if it uses a pipe.
 
 @item infd