[Mono-bugs] [Bug 59678][Blo] Changed - ASCIIEncoding chokes on large buffers

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by lupus@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=59678

--- shadow/59678	2004-06-08 11:30:33.000000000 -0400
+++ shadow/59678.tmp.18373	2004-06-09 06:11:43.000000000 -0400
@@ -32,6 +32,36 @@
 
 If you remove the ASCIIEncoder you will notice the same effect, it just
 takes longer.   With Beta1, we got to 86 megs while with Beta2 it got
 to 200 megs.
 
 The issue is related to the upgrade of the GC library.
+
+------- Additional Comments From lupus@ximian.com  2004-06-09 06:11 -------
+I sent this program to the GC mailing list: it reproduces the issue
+without mono's involvement. Also note that for me with this test there
+is no practical difference when compiled with libgc 6.2 and 6.3alpha6
+(it ends up with 450 and 439 MBs of memory usage, a small improvement
+with the new version). 6.2 is the version used in beta1, while the
+alpha6 is in the beta2 and current cvs. The large difference you see
+are likely unrelated to the libgc implementation: it just happens that
+in one case the stack appears to contain references to the allocated
+memoy blocks in one case and not in the other, but the reverse could
+happen as well, depending on mostly random factors. This is probably
+the main issue with a conservative GC and probably the only short term
+thing we can do is to try to not use huge arrays.
+#include <gc.h>
+
+void allocate (int i) {
+        char *b = GC_malloc_atomic (i * 1048576);
+        memset (b, 1, i * 1048576);
+        printf ("done with %d MB at %p\n", i, b);
+}
+
+int main () {
+        int i = 0;
+        for (i = 1; i < 50; ++i) {
+                allocate (i);
+        }
+        return 0;
+}
+