Updates.
authorPaolo Molaro <lupus@oddwiz.org>
Fri, 9 Jul 2004 16:09:08 +0000 (16:09 -0000)
committerPaolo Molaro <lupus@oddwiz.org>
Fri, 9 Jul 2004 16:09:08 +0000 (16:09 -0000)
svn path=/trunk/mono/; revision=30955

docs/precise-gc

index f0dd52e5792c77a6c118aa97f90871c9fce8ff70..8f84ea3203bb6167d52dd33c58314caa37def702 100644 (file)
@@ -8,6 +8,12 @@ This is a large task, but it can be done in steps.
 1) use the GCJ support to mark reference fields in objects, so
 scanning the heap is faster. This is mostly done already, needs
 checking that it is always used correctly (big objects, arrays).
+There are also some data structures we use in the runtime that are
+currently untyped that are allocated in the Gc heap and used to 
+keep references to GC objects. We need to make them typed as to
+precisely track GC references or make them non-GC memory,
+by using more the GC hnadle support code (MonoGHashTable, MonoDomain, 
+etc).
 
 2) don't include in the static roots the .bss and .data segments
 to save in scanning time and limit false-positives. This is mostly 
@@ -59,6 +65,12 @@ The important features needed:
 *) possibly per-thread lock-free allocation
 *) handle weakrefs and finalizers with the CLR semantics
 
+Note: some GC engines use a single mmap area, because it makes
+handling generations and the implementation much easier, but this also 
+limits the expension of the heap, so people may need to use a command-line
+option to set the max heap size etc. It would be better to have a design 
+that allows mmapping a few megabytes chunks at a time.
+
 The different tasks can be done in parallel. 1, 2 and 4 can be done in time
 for the mono 1.2 release. Parts of 3 and 5 could be done as well.
 The complete switch is supposed to happen with the mono 2.0 release.