Ticket #958: doc-fixes.patch

src/gc/api.c

@@ -1692 +1692 @@
 
 =head1 SEE ALSO
 
-F<include/parrot/gc_api.h>, F<src/cpu_dep.c> and F<docs/pdds/pdd09_gc.pod>.
+F<include/parrot/gc_api.h>, F<src/gc/system.c> and F<docs/pdds/pdd09_gc.pod>.
 
 =head1 HISTORY
 

src/runcore/cores.c

@@ -382 +382 @@
         PARROT_ASSERT(debugger);
 
         /* set the top of the stack so GC can trace it for GC-able pointers
-         * see trace_system_areas() in src/cpu_dep.c */
+         * see trace_system_areas() in src/gc/system.c */
         debugger->lo_var_ptr = interp->lo_var_ptr;
 
         pio = Parrot_io_STDERR(debugger);

docs/memory_internals.pod

@@ -117 +117 @@
 =head2 General structure of a buffer-like item
 
     struct parrot_object_t {
-        UnionVal cache;
         unsigned flags;
         ...
     } PObj;
 
-This does not totally reflect the current implementation, but is the spirit of
-the abstraction of current objects. The C<UnionVal cache> field is a C<union>
-that contains a variety of pointer and data configurations. The flags field
-may contain a series of flags which indicate the type, status, configuration,
-and special requirements of each item. Buffers, C<PMC>s, and C<PObj>s all
-have these basic fields in common, although they also contain a variety of
-other data fields, depending on type.
+The flags field may contain a series of flags which indicate the type, status, 
+configuration, and special requirements of each item. C<Buffer>s, C<PMC>s, and 
+C<PObj>s all have this basic field in common.
 
+C<PMC>s and C<Buffer>s each have an additional field which contain a pointer 
+to a block of data.
+
 =head2 GC-related PObj flags
 
 Only three flags need to be checked during a mark run: C<PObj_live_FLAG>,

docs/pdds/pdd28_strings.pod

@@ -257 +257 @@
 
 Parrot's internal strings (C<STRING>s) have the following structure:
 
-  struct parrot_string_t {
-      UnionVal                      cache;
-      Parrot_UInt                   flags;
-      UINTVAL                       bufused;
-      UINTVAL                       strlen;
-      UINTVAL                       hashval;
-      const struct _encoding       *encoding;
-      const struct _charset        *charset;
-      const struct _normalization  *normalization;
-  };
+    struct parrot_string_t {
+        Parrot_UInt flags;
+        void *     _bufstart;
+        size_t     _buflen;
+        char       *strstart;
+        UINTVAL     bufused;
+        UINTVAL     strlen;
+        UINTVAL     hashval;
+        const struct _encoding *encoding;
+        const struct _charset  *charset;
+};
 
 The fields are:
 
 =over 4
 
-=item cache
+=item _bufstart
 
-A structure that holds the buffer for the string data and the size of the
-buffer in bytes.
+A pointer to  the buffer for the string data.
 
-{{ NOTE: this is currently called "cache" for compatibility with PMC
-structures.  As we eliminate the cache from PMCs, we will flatten out this
-union value in the string structure to two members: a string buffer and the
-size of the buffer used. }}
+=item _buflen 
 
+The size of the buffer in bytes.
+
 =item flags
 
 Binary flags used for garbage collection, copy-on-write tracking, and other
@@ -320 +319 @@
 The charset structure specifies the character set (by index number and by
 name) and provides functions for transcoding to and from that character set.
 
-=item normalization
-
-What normalization form the string data is in, one of the four Unicode
-normalization forms or NFG. This structure stores the current normalization
-form, function pointers for composition and decomposition for the current
-normalization form, and a pointer to the grapheme table for NFG.
-
 =back
 
 {{DEPRECATION NOTE: the enum C<parrot_string_representation_t> will be removed

include/parrot/pobj.h

@@ -38 +38 @@
                     v                 v
 
 The actual set-up is more involved because of padding.  obj->bufstart must
-be suitably aligned for any UnionVal.  (Perhaps it should be a Buffer
-there instead.)  The start of the memory region (as returned by malloc()
-is also suitably aligned for any use.  If, for example, malloc() returns
+be suitably aligned. The start of the memory region (as returned by malloc())
+is suitably aligned for any use.  If, for example, malloc() returns
 objects aligned on 8-byte boundaries, and obj->bufstart is also aligned
 on 8-byte boundaries, then there should be 4 bytes of padding.  It is
 handled differently in the two files alloc_resources.c and res_lea.c.