Permalink
Browse files

Added the docs dir to the dist (with a new doc on GC issues).

Removed defunct wrapper dir.
Fixed make distcheck in jit.
Really build monoburg if needed.

svn path=/trunk/mono/; revision=3492
  • Loading branch information...
illupus committed Mar 29, 2002
1 parent b2136d6 commit b1a7c0e3f741e868d902c6d07cf27f7cee1da82f
Showing with 39 additions and 2 deletions.
  1. +1 −1 Makefile.am
  2. +1 −1 configure.in
  3. +3 −0 docs/Makefile.am
  4. +31 −0 docs/gc-issues
  5. +1 −0 mono/jit/Makefile.am
  6. +2 −0 mono/monoburg/Makefile.am
View
@@ -1,3 +1,3 @@
AUTOMAKE_OPTIONS = foreign
-SUBDIRS = mono doc runtime scripts man
+SUBDIRS = mono doc docs runtime scripts man
View
@@ -475,7 +475,6 @@ mono/arch/sparc/Makefile
mono/arch/arm/Makefile
mono/interpreter/Makefile
mono/tests/Makefile
-mono/wrapper/Makefile
mono/monoburg/Makefile
mono/monograph/Makefile
mono/jit/Makefile
@@ -484,6 +483,7 @@ runtime/Makefile
scripts/Makefile
man/Makefile
doc/Makefile
+docs/Makefile
])
echo "
View
@@ -0,0 +1,3 @@
+EXTRA_DIST = gc-issues jit-thoughts object-layout unmanaged-calls \
+ exceptions jit-debug jit-trampolines stack-alignment
+
View
@@ -0,0 +1,31 @@
+* GC issues you need to be careful about when hacking on the mono runtime.
+
+mono currently uses the Boehm garbage collection library. This is a conservative
+GC package: this means that the memory is searched for possible memory references
+to chunks allocated with the GC. Not all the memory is searched, but only the memory
+allocated with the GC itself (unless you use the 'atomic' variant of the allocation
+routines), the stack and global variables. Also, if the last reference to an object
+is stored in an area of themory that is not searched, the object may be freed resulting
+in memory corruption ind segfaults.
+
+In particular, memory allocated with system's malloc() is not searched, so you need to be
+careful NOT to store object references in memory allocated with malloc() (unless you are sure
+that the object reference will be live at the same time in some other area under the control
+of the GC (on the stack or in a global variable, for example). Since g_malloc()
+ultimately calls system malloc() the data structures in GLib are not safe to
+use to store object references.
+
+Occasionally, you'll need to store some object reference from C code: in this case,
+you must make sure that the store location is searched by the GC. You can safely
+use thread local storage areas, global variables, stack variables. If you need a more
+complicated data structure, you can use a hash table: MonoGHashTable.
+This hash table has the same interface as GHashTable from GLib, just stick the "mono_"
+prefix in function calls and the "Mono" prefix in the hash table type name.
+This hash table ensures that object references stored in it are tracked by the GC, as long
+as the pointer to the hash is tracked itself.
+
+Other data structures that are allocated with the GC and are safe to use to store pointers
+to GC-allocated memory, are MonoDomain (keeps track of many domain specfic objects)
+and MonoVTable (referenced by MonoDomain: keeps track of the static data of a type
+since that can hold references to objects).
+
View
@@ -26,6 +26,7 @@ libmono_a_SOURCES = \
delegate.c \
exception.c \
invoke.c \
+ message.h \
message.c
mono_SOURCES = mono.c
@@ -5,6 +5,8 @@ CC=$(CC_FOR_BUILD)
#sample_SOURCES = sample.c
+all: monoburg$(BUILD_EXEEXT)
+
parser.c: $(srcdir)/monoburg.y
bison $(srcdir)/monoburg.y -o parser.c

0 comments on commit b1a7c0e

Please sign in to comment.