diff options
author | Paolo Molaro <lupus@oddwiz.org> | 2002-03-29 11:18:03 +0300 |
---|---|---|
committer | Paolo Molaro <lupus@oddwiz.org> | 2002-03-29 11:18:03 +0300 |
commit | b1a7c0e3f741e868d902c6d07cf27f7cee1da82f (patch) | |
tree | 3fc1c80b0f6a335c0d2fff772987902c702c9bb6 /docs | |
parent | b2136d6dec21ef8e2a667a9bb2b42e5291cc815a (diff) |
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
Diffstat (limited to 'docs')
-rw-r--r-- | docs/Makefile.am | 3 | ||||
-rw-r--r-- | docs/gc-issues | 31 |
2 files changed, 34 insertions, 0 deletions
diff --git a/docs/Makefile.am b/docs/Makefile.am new file mode 100644 index 00000000000..c88f3540475 --- /dev/null +++ b/docs/Makefile.am @@ -0,0 +1,3 @@ +EXTRA_DIST = gc-issues jit-thoughts object-layout unmanaged-calls \ + exceptions jit-debug jit-trampolines stack-alignment + diff --git a/docs/gc-issues b/docs/gc-issues new file mode 100644 index 00000000000..95062c56244 --- /dev/null +++ b/docs/gc-issues @@ -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). + |