Nabble - Mono - Garbage Collection

Re: Two types of memory issues

2009-02-08T23:01:11Z

jornare wrote:

Error 1)
"Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS"
This error usually seems to be associated with the StringBuilder class, and I have managed to overcome a few of the instances where it crashes by avoiding to use StringBuilder.

So, how do i Increase MAXINCHR and/or MAX_HEAP_SECTS? -And will this be a finite solution?

You need to rebuild the Boehm's collector used in MONO. There is some configure options dealing with that.

I forgot the details, and I am not a Mono expert.

Perhaps future Mono releases (and even the current Mono trunk) provide a generational garbage collector which helps with that issue. So, you might try the Mono trunk, with its experimental GC enabled.

Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Two types of memory issues

2008-11-19T01:21:33Z

Hi all!

I'm creating an app which is constantly creating worker-threads (as many as possible) using lots of CPU and heaps of memory allocations.

I have a AMD64bit server with 32GB RAM and 8 cores which it runs on. The program is compiled in .Visual Studio Express on Win64, copied to the server running mono 2.0.1 (C#)

After running a few hours I seem to constantly be running into the same memory issues, which I believe is with the garbage collector or the configuration of it. When it crashes it usually has a

Error 1)
"Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS"
This error usually seems to be associated with the StringBuilder class, and I have managed to overcome a few of the instances where it crashes by avoiding to use StringBuilder.

So, how do i Increase MAXINCHR and/or MAX_HEAP_SECTS? -And will this be a finite solution?

Error 2)
mmap(...PROT_NONE...) failed
Stacktrace:
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_object_new_f ast (intptr) <0x00048>
at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_object_new_f ast (intptr) <0xffffffff>
at ......

followed by

Native stacktrace:

mono [0x428742]
/usr/app/glibc/current/lib/libpthread.so.0 [0x7fb65b81d4b0]
/usr/app/glibc/current/lib/libc.so.6(gsignal+0x3b) [0x7fb65b279ffb]
/usr/app/glibc/current/lib/libc.so.6(abort+0x110) [0x7fb65b27b4e0]

Any ideas on this one?

Thanx,

jornare

Re: Compacting GC (again)

2008-11-18T09:00:45Z

On Tue, Nov 18, 2008 at 1:13 PM, Ciprian Mustiata <ciprian.mustiata@...> wrote:

Hello,

Great achievements with the Linear IL runtime and Mono.SIMD optimizations. The linked-list allocators as Visual C++'s runtime new and delete works for a large amount of small objects (the worse case anyway for a C++ program) around 10-40 times slower than the GC allocation in C#. Anyway, mono allocations/deallocations took (again in my microbenchmarks) around of the speed of C++. I've happily read about the 2.2+ versions will try to include the compacting GC.

The question is: for microbenchmarks with small objects, that will be the main thing that will be tested when someone will use the CompactingGC (and for typical desktop programs that do processing, like a XML processing logic or ASP.NET applications), what should be the typical gain on mater of speed? Can be enabled right now to test it from SVN code?

The new generational gc is faster than the current one but the main advantage is the smaller pause times.

Right now you can do a custom build of mono with the new gc enabled. It's a very experimental feature and it's neither complete or ready for general use, so use at your our risk.

Best achievements forward in Mono's future!
Ciprian Mustiata

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Compacting GC (again)

2008-11-18T07:13:46Z

Hello,

Great achievements with the Linear IL runtime and Mono.SIMD optimizations. The linked-list allocators as Visual C++'s runtime new and delete works for a large amount of small objects (the worse case anyway for a C++ program) around 10-40 times slower than the GC allocation in C#. Anyway, mono allocations/deallocations took (again in my microbenchmarks) around of the speed of C++. I've happily read about the 2.2+ versions will try to include the compacting GC.

The question is: for microbenchmarks with small objects, that will be the main thing that will be tested when someone will use the CompactingGC (and for typical desktop programs that do processing, like a XML processing logic or ASP.NET applications), what should be the typical gain on mater of speed? Can be enabled right now to test it from SVN code?

Best achievements forward in Mono's future!
Ciprian Mustiata

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: Gen GC release target

2008-10-10T04:08:05Z

On 10/09/08 peger wrote:
> Hi, was wondering if anybody knows what the release target is for the
> generational GC into mainline Mono? With ASP.NET supported and the JIT
> drastically improved in 2.0 / 2.next, the current GC seems to be the only
> thing holding us back for some of our (garbage heavy) ASP.NET apps. Any
> guess would be a help too! :-)

Mono 1.9/2.0 have already a few GC speedups.
After 2.2 we'll work on integrating the new GC in the default build.
The release where it will actually be a default will depend on how
well it will behave in the real world (many apps that currently
depend on a non-moving GC will likely break, so it will take time
to fix them, too). We hope for 2.4, but it may happen for 2.6 or later
if there are many problems (boehm GC took years to stabilize after it
was used inside mono).

> Additionally, every though of cannibalizing some other project, say OpenJDK?
> They've definitely got more than an few production-ready GCs, though i'm not
> sure about licensing...

GCs implemented for other systems are basically useless, even if they
have a compatible license (which openjdk doesn't).
One reason is that the a lot of effort is in changing the JIT and the
runtime to support a moving GC, something like openjdk's GC would
increase this effort, since it has different requirements and a much more
complex interface.
Another is that those GCs may be unable or may be completely untuned
for patterns we must implement (pinning, for example).
In some other cases, they don't support things like value types and
managed pointers (again openjdk).
Then there are other issues: we don't want a GC that takes twice as much
memory as the current one (see the shootout results for examples).
Besides openjdk, I'm not sure there is actually any production-ready
GC around that has at least some of the features needed by mono.

lupus

--
-----------------------------------------------------------------
lupus@... debian/rules
lupus@... Monkeys do it better
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Gen GC release target

2008-10-09T09:46:20Z

Hi, was wondering if anybody knows what the release target is for the generational GC into mainline Mono? With ASP.NET supported and the JIT drastically improved in 2.0 / 2.next, the current GC seems to be the only thing holding us back for some of our (garbage heavy) ASP.NET apps. Any guess would be a help too! :-)

Additionally, every though of cannibalizing some other project, say OpenJDK? They've definitely got more than an few production-ready GCs, though i'm not sure about licensing...

Regards & TIA

Re: Help with Debuging Interop Code with Mono

2008-08-15T07:41:47Z

You can use the suppresion file for running mono under valgrind, it's mono/data/mono.supp. It helps
a lot by reducing the noise.

On Fri, Aug 15, 2008 at 11:26 AM, Charlie.M <charlie.mas@...> wrote:

Hi all,

I am currently trying to debug some code C# I have written. Its a wrapper
around a native library (LibVorbis), I have it working on Windows with .net
fine but when I run it on Mono it Seg Faults. At the moment I think its
likely to be a bug in my code which windows tolerates and Linux doesn't.

I tried to find the problem by running my app in Valgrind. Unfortunately it
produces a large number of false positives during normal operation with
Mono, I assume Mono's GC confuses Valgrind. It also doesn't appear to show
an obvious source of my problems.

This happens in the latest release of Mono. However recently I have switched
to using a build I made from SVN and I have also built and installed the
mono debugger. I have been using a recent SVN build of Mono Develop which
includes its new debugger, both for Mono and Native code.

The Managed stack trace from where my code crashes seems to be completely
random, so I assume its getting screwed up somewhere before it actually
segfaults. However it always segfaults when the garbage collector is running
the GC_mark_from function at line 724 of mark.c according to the Mono
Develop debugger.

Can someone who's familiar with the Mono's GC tell me what its doing at this
point. Also is it possible to figure out which structure / object is causing
the GC problems. Any other suggestions would be greatly appreciated.

Charlie M
--
View this message in context: http://www.nabble.com/Help-with-Debuging-Interop-Code-with-Mono-tp18999561p18999561.html
Sent from the Mono - Garbage Collection mailing list archive at Nabble.com.

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Help with Debuging Interop Code with Mono

2008-08-15T07:26:04Z

Hi all,

I am currently trying to debug some code C# I have written. Its a wrapper around a native library (LibVorbis), I have it working on Windows with .net fine but when I run it on Mono it Seg Faults. At the moment I think its likely to be a bug in my code which windows tolerates and Linux doesn't.

I tried to find the problem by running my app in Valgrind. Unfortunately it produces a large number of false positives during normal operation with Mono, I assume Mono's GC confuses Valgrind. It also doesn't appear to show an obvious source of my problems.

This happens in the latest release of Mono. However recently I have switched to using a build I made from SVN and I have also built and installed the mono debugger. I have been using a recent SVN build of Mono Develop which includes its new debugger, both for Mono and Native code.

The Managed stack trace from where my code crashes seems to be completely random, so I assume its getting screwed up somewhere before it actually segfaults. However it always segfaults when the garbage collector is running the GC_mark_from function at line 724 of mark.c according to the Mono Develop debugger.

Can someone who's familiar with the Mono's GC tell me what its doing at this point. Also is it possible to figure out which structure / object is causing the GC problems. Any other suggestions would be greatly appreciated.

Charlie M

Re: Weird Garbage Collection behaviour with finalizers

2008-08-04T11:07:51Z

I solved the memory "leak" by adding
GC.WaitForPendingFinalizers();
inside the loop, but shouldn't this done by the GC internally?
The run time reduced to 20 seconds, but that is 5 times more than without finalizer! Without an EMPTY finalizer.

Weird Garbage Collection behaviour with finalizers

2008-08-04T07:10:49Z

Hi!

I have downloaded the Mono 2.0 preview release today to make some performance comparisions with the MS Runtime. So I wrote a simple application to test massive object creation and the garbace collection auto-cleanup functionality:


using System;

using System.Collections.Generic;

using System.Text;

using System.Timers;



namespace GarbageCollectionTest

{

    class TestClass

    {

        private string mData;

        public TestClass(int i)

        {

            mData = i.ToString();

        }

        /*~TestClass()

        {

        }*/

    };



    class Program

    {

        static void Main(string[] args)

        {

            DateTime start = DateTime.Now;

            TestClass class1 = null;

            for (int i = 0; i < 10000000; ++i)

            {

                class1 = new TestClass(i);

                class1 = null;

            }

            Console.WriteLine("time elapsed: {0}", DateTime.Now.Subtract(start));

            Console.ReadKey();

        }

    }

}

When I run this with the Microsoft Runtime it takes 2250ms. With the mono runtime it took 4000ms. The next thing I tried was to add an finalizer to my test class. I started the application with the MS Runtime and it took 5700 ms. I started the same application with mono and it took 2 minutes while the memory usage was raising continually.

I think that there is a memory leak somewhere in the Mono GC implementation or is there something about the Mono GC that is different to the MS one I missed?

Thanks & Regards,
Urs

Re: GC and multiple inheritance as in C++

2008-06-13T11:46:43Z

I believe the answer here is: “no”. MI languages have to find a way to fake it.

Microsoft’s C++/CLI fakes it by not allowing MI for managed types. MI classes are represented as value types in the CLI and thus don’t behave with “true” polymorphism. They do in the sense that C++ code compiled together works correctly, but to other languages the inheritance is opaque – calling GetType().BaseType will just yield System.ValueType.

The CLR port of Eiffel fakes it by using a [somewhat complex and arcane] scheme where inheritance in Eiffel is modeled with interfaces in .NET.

Jason

From: mono-gc-list-bounces@... [mailto:mono-gc-list-bounces@...] On Behalf Of Juro Jon
Sent: Thursday, June 12, 2008 8:36 PM
To: mono-gc-list@...
Subject: Re: [Mono-gc-list] GC and multiple inheritance as in C++

I don't know much of CLI specification so I may be missing something trivial. Java GC assumes that all pointers point to some "header" to identity the memory object. Since Java is single inheritance a pointer always points to the head of a full object, but for C++ multiple inheritance it may be pointing to an embedded part and need to be adjusted to find the full object. Are you saying that the CLI GC or typesystem has some way to do this adjustment?

Thanks

On Fri, Jun 13, 2008 at 3:50 AM, David Jeske <jeske@...> wrote:

-- Juro Jon wrote:
> Hello, I have a question concerning implementation of multiple inheritance in
> CIL. For a C++ MI object, a pointer can points to inside the object body
> instead of the its head. eg.
> struct A : B, C { }; C* c = new A;
> While Boehm GC detects this kind of reference, is it a supported feature of
> Mono? If not, what is the suggested way to implement it (eg. what is the
> C++/CLI way) ?

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: GC and multiple inheritance as in C++

2008-06-12T18:40:42Z

I think my optimism may have got the better of me. The CLR has a mechanism to
handle internal references, but I don't believe this answers your question or
solves your issue. The CLI GC handles interior references to objects even in C#
for "byref" paramaters, but only for interior references on the stack. Here are
some potentially useful references:

(see the bottom of this for comments on Rotor)
http://blogs.msdn.com/joelpob/archive/2004/02/26/80776.aspx
http://ksrenevasan.blogspot.com/2005/08/incomplete-rotor-gc-notes.html

Partition I, section 12.4.1.5.2, it talks about byref and lifetimes.
Partition II, section 12, it talks about interfaces and mentions MI.

----

However, it occurs to me that in C++ MI you may need interior pointers that are
not on the stack. Your concern may be well-founded, as the snippets I can find
only talk about Rotor tracing interior references which are on the stack.

Perhaps someone with more knowledge can offer a more complete (or accurate)
answer.

-- Juro Jon wrote:
> I don't know much of CLI specification so I may be missing something
> trivial. Java GC assumes that all pointers point to some "header" to
> identity the memory object. Since Java is single inheritance a pointer
> always points to the head of a full object, but for C++ multiple inheritance
> it may be pointing to an embedded part and need to be adjusted to find the
> full object. Are you saying that the CLI GC or typesystem has some way to do
> this adjustment?
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: GC and multiple inheritance as in C++

2008-06-12T18:36:22Z

On Fri, Jun 13, 2008 at 3:50 AM, David Jeske <jeske@...> wrote:

AFAIK, you don't need C++ MI to have a pointer to something inside an object
body. This can happen if you take a ref of any instance data in C#.

http://www.java2s.com/Code/CSharp/Language-Basics/CRefandOutParameters.htm

-- Juro Jon wrote:
> Hello, I have a question concerning implementation of multiple inheritance in
> CIL. For a C++ MI object, a pointer can points to inside the object body
> instead of the its head. eg.
> struct A : B, C { }; C* c = new A;
> While Boehm GC detects this kind of reference, is it a supported feature of
> Mono? If not, what is the suggested way to implement it (eg. what is the
> C++/CLI way) ?

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: GC and multiple inheritance as in C++

2008-06-12T10:50:56Z

AFAIK, you don't need C++ MI to have a pointer to something inside an object
body. This can happen if you take a ref of any instance data in C#.

http://www.java2s.com/Code/CSharp/Language-Basics/CRefandOutParameters.htm

-- Juro Jon wrote:
> Hello, I have a question concerning implementation of multiple inheritance in
> CIL. For a C++ MI object, a pointer can points to inside the object body
> instead of the its head. eg.
> struct A : B, C { }; C* c = new A;
> While Boehm GC detects this kind of reference, is it a supported feature of
> Mono? If not, what is the suggested way to implement it (eg. what is the
> C++/CLI way) ?
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

GC and multiple inheritance as in C++

2008-06-10T20:48:54Z

Hello, I have a question concerning implementation of multiple inheritance in CIL. For a C++ MI object, a pointer can points to inside the object body instead of the its head. eg.
struct A : B, C { }; C* c = new A;
While Boehm GC detects this kind of reference, is it a supported feature of Mono? If not, what is the suggested way to implement it (eg. what is the C++/CLI way) ?

Thanks you

Re: -DPARALLEL_MARK and GC_enable_incremental()

2008-03-20T03:48:50Z

On 03/19/08 Jonathan Gagnon wrote:
> I wanted to know how the mono GC behaves on multiprocessor machines. After
> reading some documentation on the Boehm GC, I'm wondering if mono compiles
> the GC with -DPARALLEL_MARK. This allows the collector to run the mark
> phase in parallel, and thus use all the available processors on a
> multi-processor machine (instead of using just one). More details can be
> found here :
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html

Some time ago I tested a mono version enabled with -DPARALLEL_MARK
on a workload that should have benefited from it and I saw basiccally no
performance improvement on my core 2 duo (there was a slight regression).
For kicks I just tested another case and with parallel marking
enabled performance is orrible (twice as slow).
You can easily test your workload configuring mono with the
--enable-parallel-mark option.
I didn't investigate the cause of the slowdown.

> It seems like they also have generational collection, that can be enable by
> calling GC_enable_incremental. It doesn't seem to be called anywhere in the
> mono sources, so I assume it is not used. Is there a reason why?

GC_enable_incremental has a number of issues that are detailed in the
documentation (mainly unexpected interrupted syscalls: we could deal
with them in the runtime, but the p/invoke code of many programs would
break unless we copy potentially lots of data around: not practical).

lupus

--
-----------------------------------------------------------------
lupus@... debian/rules
lupus@... Monkeys do it better
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

-DPARALLEL_MARK and GC_enable_incremental()

2008-03-19T09:39:15Z

Hi,

I wanted to know how the mono GC behaves on multiprocessor machines. After reading some documentation on the Boehm GC, I'm wondering if mono compiles the GC with -DPARALLEL_MARK. This allows the collector to run the mark phase in parallel, and thus use all the available processors on a multi-processor machine (instead of using just one). More details can be found here :

http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html

It seems like they also have generational collection, that can be enable by calling GC_enable_incremental. It doesn't seem to be called anywhere in the mono sources, so I assume it is not used. Is there a reason why?

Thanks,

Jonathan

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Request for backport of garbage collection patch

2007-07-30T09:33:38Z

> Right. The problem is that mono 1.2 fails horribly under wine, whereas
> mono 1.1 works pretty well. I'm working on getting mono 1.2 to run
> under wine, but having a fully-functional 1.1 runtime would help.

It would be interesting to know how Mono 1.2 fails with Wine, there is
not much in this email that we can act on.

> The intention is not to stick with 1.1.*, but use it until wine can
> successfully host a 1.2 runtime.
>
> matt
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@...
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Request for backport of garbage collection patch

2007-07-26T12:29:57Z

On 7/26/07, Paolo Molaro <lupus@...> wrote:

> On 07/17/07 Matt Jones wrote:
> > I'm working on improving mono-under-wine (on the wine side), and I've
> [...]
> > Any chance this patch could be applied to the maintenance branch? The
> > patch applies cleanly to 1.13.8.2.
>
> I really hope you're not basing your improvements on mono 1.13.x: it
> is a really old release which nobody should use at this time
> (especially not to build something new like wine support upon it).
> Use mono version 1.2.4 (or the upcoming 1.2.5).

Right. The problem is that mono 1.2 fails horribly under wine, whereas
mono 1.1 works pretty well. I'm working on getting mono 1.2 to run
under wine, but having a fully-functional 1.1 runtime would help.

The intention is not to stick with 1.1.*, but use it until wine can
successfully host a 1.2 runtime.

matt
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Request for backport of garbage collection patch

2007-07-26T03:13:39Z

On 07/17/07 Matt Jones wrote:
> I'm working on improving mono-under-wine (on the wine side), and I've
[...]
> Any chance this patch could be applied to the maintenance branch? The
> patch applies cleanly to 1.13.8.2.

I really hope you're not basing your improvements on mono 1.13.x: it
is a really old release which nobody should use at this time
(especially not to build something new like wine support upon it).
Use mono version 1.2.4 (or the upcoming 1.2.5).

lupus

--
-----------------------------------------------------------------
lupus@... debian/rules
lupus@... Monkeys do it better
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-24T07:43:48Z

On 07/24/07 Jonathan Gagnon wrote:
> I'm pretty sure that this will fix bug #81727 that I filed a few months ago,
> although I don't have time to test it for the moment.

Thanks, confirmed that issue is fixed as well.

lupus

--
-----------------------------------------------------------------
lupus@... debian/rules
lupus@... Monkeys do it better
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-24T06:58:49Z

I'm pretty sure that this will fix bug #81727 that I filed a few months ago,
although I don't have time to test it for the moment.

Jonathan Gagnon

-----Message d'origine-----
De : mono-devel-list-bounces@...
[mailto:mono-devel-list-bounces@...] De la part de Miguel de
Icaza
Envoyé : Wednesday, July 18, 2007 8:17 PM
À : David Wolinsky
Cc : Andreas Färber; Peer-to-peer networking group discussions;
mono-gc-list@...; mono-devel
Objet : Re: [Mono-dev] [Mono-gc-list] Mono memory problems!

Hello folks,

Thanks for tracking this problem down.

Thanks for pointing out the comment in the source code; I went and
re-read the documentation and I clearly did not understand it the first time
over, because the leak was documented to happen only in the .NET 1.0 and 1.1
scenarios, not on the 2.0 scenario.

So the fix that takes ownership is correct. I tidied up the patch
a little bit as well. The fix is now on svn, thanks again for tracking
this down.

> In fact, I was able to fix the problem.
>
> For some reason in WaitHandle.cs, the line...
> safe_wait_handle = new SafeWaitHandle (value, false); should be...
> safe_wait_handle = new SafeWaitHandle (value, true); (at least it
> makes sense according to other docs I read)...
>
> second... in SafeWaitHandle.cs, the line ...
> NativeEventCalls.CloseEvent_internal
> (DangerousGetHandle()); should be...
> NativeEventCalls.CloseEvent_internal (handle);
>
> The second one is kind of silly because Release gets called only after
> refcount == 0, but calling DangerousGetHandle throws an exception if
> refcount == 0.
>
> I think there is still a problem of the array of wapi handles not
> being shrunk down, but that complexity is beyond me.
>
> Regards,
> David
>
> Andreas Färber wrote:
> >
> > Am 18.07.2007 um 19:54 schrieb David Wolinsky:
> >
> >> That case leaks as well.
> >>
> >> Regards,
> >> David
> >>
> >> Miguel de Icaza wrote:
> >>>> re = new AutoResetEvent(false);
> >>>> re.Close();
> >>>
> >>> That depends on the finalizer to run to release memory from the
> >>> unmanaged side, since AutoResetEvent implements IDisposable you
> >>> should use it like this:
> >>>
> >>> using (re = AutoResetEvent (false)) {
> >>> ...
> >
> > Doesn't Close() call Dispose()? At least for the Stream classes it
> > should.
> >
> > Andreas
> >
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@...
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@...
http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T15:16:59Z

Bugzilla report and patch

Regards,
David

http://bugzilla.ximian.com/show_bug.cgi?id=82134
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T14:30:54Z

In fact, I was able to fix the problem.

For some reason in WaitHandle.cs, the line...
safe_wait_handle = new SafeWaitHandle (value, false);
should be...
safe_wait_handle = new SafeWaitHandle (value, true);
(at least it makes sense according to other docs I read)...

second... in SafeWaitHandle.cs, the line ...
NativeEventCalls.CloseEvent_internal (DangerousGetHandle());
should be...
NativeEventCalls.CloseEvent_internal (handle);

The second one is kind of silly because Release gets called only after
refcount == 0, but calling DangerousGetHandle throws an exception if
refcount == 0.

I think there is still a problem of the array of wapi handles not being
shrunk down, but that complexity is beyond me.

Regards,
David

Andreas Färber wrote:

>
> Am 18.07.2007 um 19:54 schrieb David Wolinsky:
>
>> That case leaks as well.
>>
>> Regards,
>> David
>>
>> Miguel de Icaza wrote:
>>>> re = new AutoResetEvent(false);
>>>> re.Close();
>>>
>>> That depends on the finalizer to run to release memory from the
>>> unmanaged side, since AutoResetEvent implements IDisposable you should
>>> use it like this:
>>>
>>> using (re = AutoResetEvent (false)) {
>>> ...
>
> Doesn't Close() call Dispose()? At least for the Stream classes it
> should.
>
> Andreas
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T11:54:49Z

That case leaks as well.

Regards,
David

Miguel de Icaza wrote:

>> namespace Ipop {
>> public class IPOP_Common {
>> public static void Main() {
>> AutoResetEvent re = null;
>> while(true) {
>> re = new AutoResetEvent(false);
>> re.Close();
>> }
>> }
>> }
>> }
>>
>> blows up memory
>>
>
> That depends on the finalizer to run to release memory from the
> unmanaged side, since AutoResetEvent implements IDisposable you should
> use it like this:
>
> using (re = AutoResetEvent (false)) {
> ...
>
> Miguel
>
>> whereas ...
>>
>> using System.Security.Cryptography;
>> using System;
>>
>> namespace Ipop {
>> public class IPOP_Common {
>> public static void Main() {
>> RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
>> while(true) {
>> byte[] key = new byte[1024];
>> rng.GetBytes(key);
>> }
>> }
>> }
>> }
>>
>> This doesn't.
>>
>> David Wolinsky wrote:
>>
>>> We run this software on system where memory is a concern. The data that
>>> we presented is our test case system that has 50 nodes all running in
>>> the same mono process. We run only a single node at each site which
>>> initially starts at ~15 MB, we've seen it swell to well over 300 MBs in
>>> a period of less than a week. Since this must be used in production
>>> environments and is meant to be extremely lightweight we can forgive a
>>> small memory portion like 15 MB, since it has relatively no processing
>>> overhead, but at over 300 MBs our processes are often stopped by the
>>> remote admin and we are told to clean up the problem.
>>>
>>> Since this seems to be a problem of using a non-compacting gc, do you
>>> know where the compacting gc is, so that we could at least test it out.
>>> I searched the SVN and found no clues of it.
>>>
>>> Also, I should correct myself, the results for memory consumption were
>>> not directly related to the test that grows at 25kB/sec. I found this
>>> out after posting the data, I am running heap-shot right now with the
>>> correct test and it has grown 100MB in less than 1 hour.
>>>
>>> Regards,
>>> David
>>>
>>>
>>>
>>> Alan McGovern wrote:
>>>
>>>
>>>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have
>>>> over 1 gig of memory allocated. As you don't, i think what you're
>>>> seeing is just 'normal usage' for the non-compacting GC that mono
>>>> uses. I have a similar app which uses sockets extensively (50-150
>>>> simultaneous connections) and i can assure you that memory usage
>>>> doesn't get unbearably large. It'd be interesting to see the logs but
>>>> i don't think there's much to be worried about.
>>>>
>>>> Alan.
>>>>
>>>> On 7/18/07, *David Wolinsky* <davidiw@...
>>>> <mailto:davidiw@...>> wrote:
>>>>
>>>> Initially 45 MB, 12 hours later 147 MB
>>>>
>>>> Another developer has the heap-shot logs, I'll post those as soon as
>>>> possible.
>>>>
>>>> David
>>>>
>>>> Alan McGovern wrote:
>>>> > Could you post up the detailed stats from heapshot? After the 12
>>>> hour
>>>> > run, how much memory are you using? Are we talking in the gigabyte
>>>> > range, or megabyte range?
>>>> >
>>>> > Alan.
>>>> >
>>>> > On 7/18/07, *David Wolinsky* <davidiw@...
>>>> <mailto:davidiw@...>
>>>> > <mailto:davidiw@... <mailto:davidiw@...>>> wrote:
>>>> >
>>>> > My lab works on a peer-to-peer network overlay and we've noticed
>>>> > recently significant memory issues. Some background...
>>>> >
>>>> > This application is constantly creating new objects and shortly
>>>> > thereafter deleting (removing reference to) them
>>>> > Using a sample run with 150 threads running...
>>>> > Mono on Linux has a growth rate of ~25 KB per second with a
>>>> base
>>>> > of 50MB
>>>> > (y = 25K *x + 50M)
>>>> > .NET on Windows stabilizes at 35 MB
>>>> >
>>>> > We ran heap-shot with Linux and found that in a 12 hour
>>>> period it
>>>> > reported this...
>>>> > start:
>>>> > objects: 58,823
>>>> > heap memory: 6,838,426 bytes
>>>> >
>>>> > end:
>>>> > objects: 59,925
>>>> > heap memory: 6,862,336
>>>> >
>>>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size
>>>> > (RES) got
>>>> > significantly bigger than it.
>>>> >
>>>> > I have searched for the Compacting GC with no luck, we would
>>>> > really like
>>>> > to see if it would help our problem.
>>>> >
>>>> > The only operating system resources we're using are Sockets, but
>>>> > we use
>>>> > them VERY heavily!
>>>> >
>>>> > If anyone has any suggestions, we'd be open to test out
>>>> anything
>>>> > at this
>>>> > point!
>>>> >
>>>> > We are leaning towards an issue in unmanaged memory and
>>>> possibly a bug
>>>> > in mono.
>>>> >
>>>> > Best regards,
>>>> > David
>>>> >
>>>> >
>>>> > ps, I fwded this to gc and devel list because gc list looks
>>>> quite
>>>> > dead.... sorry for the duplication
>>>> > _______________________________________________
>>>> > Mono-devel-list mailing list
>>>> > Mono-devel-list@...
>>>> <mailto:Mono-devel-list@...>
>>>> > <mailto:Mono-devel-list@...
>>>> <mailto:Mono-devel-list@...>>
>>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Mono-gc-list maillist - Mono-gc-list@...
>>> http://lists.ximian.com/mailman/listinfo/mono-gc-list
>>>
>>>
>>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list@...
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T09:49:29Z

FYI, this case is only triggered when using gmcs and not mcs.

David

David Wolinsky wrote:

> We've isolated the problem down to AutoResetEvent...
>
> using System;
> using System.Threading;
>
> namespace Ipop {
> public class IPOP_Common {
> public static void Main() {
> AutoResetEvent re = null;
> while(true) {
> re = new AutoResetEvent(false);
> re.Close();
> }
> }
> }
> }
>
> blows up memory
>
> whereas ...
>
> using System.Security.Cryptography;
> using System;
>
> namespace Ipop {
> public class IPOP_Common {
> public static void Main() {
> RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
> while(true) {
> byte[] key = new byte[1024];
> rng.GetBytes(key);
> }
> }
> }
> }
>
> This doesn't.
>
> David Wolinsky wrote:
>> We run this software on system where memory is a concern. The data
>> that we presented is our test case system that has 50 nodes all
>> running in the same mono process. We run only a single node at each
>> site which initially starts at ~15 MB, we've seen it swell to well
>> over 300 MBs in a period of less than a week. Since this must be
>> used in production environments and is meant to be extremely
>> lightweight we can forgive a small memory portion like 15 MB, since
>> it has relatively no processing overhead, but at over 300 MBs our
>> processes are often stopped by the remote admin and we are told to
>> clean up the problem.
>>
>> Since this seems to be a problem of using a non-compacting gc, do you
>> know where the compacting gc is, so that we could at least test it
>> out. I searched the SVN and found no clues of it.
>>
>> Also, I should correct myself, the results for memory consumption
>> were not directly related to the test that grows at 25kB/sec. I
>> found this out after posting the data, I am running heap-shot right
>> now with the correct test and it has grown 100MB in less than 1 hour.
>>
>> Regards,
>> David
>>
>>
>>
>> Alan McGovern wrote:
>>
>>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have
>>> over 1 gig of memory allocated. As you don't, i think what you're
>>> seeing is just 'normal usage' for the non-compacting GC that mono
>>> uses. I have a similar app which uses sockets extensively (50-150
>>> simultaneous connections) and i can assure you that memory usage
>>> doesn't get unbearably large. It'd be interesting to see the logs
>>> but i don't think there's much to be worried about.
>>>
>>> Alan.
>>>
>>> On 7/18/07, *David Wolinsky* <davidiw@...
>>> <mailto:davidiw@...>> wrote:
>>>
>>> Initially 45 MB, 12 hours later 147 MB
>>>
>>> Another developer has the heap-shot logs, I'll post those as
>>> soon as
>>> possible.
>>>
>>> David
>>>
>>> Alan McGovern wrote:
>>> > Could you post up the detailed stats from heapshot? After the 12
>>> hour
>>> > run, how much memory are you using? Are we talking in the
>>> gigabyte
>>> > range, or megabyte range?
>>> >
>>> > Alan.
>>> >
>>> > On 7/18/07, *David Wolinsky* <davidiw@...
>>> <mailto:davidiw@...>
>>> > <mailto:davidiw@... <mailto:davidiw@...>>> wrote:
>>> >
>>> > My lab works on a peer-to-peer network overlay and we've
>>> noticed
>>> > recently significant memory issues. Some background...
>>> >
>>> > This application is constantly creating new objects and
>>> shortly
>>> > thereafter deleting (removing reference to) them
>>> > Using a sample run with 150 threads running...
>>> > Mono on Linux has a growth rate of ~25 KB per second with a
>>> base
>>> > of 50MB
>>> > (y = 25K *x + 50M)
>>> > .NET on Windows stabilizes at 35 MB
>>> >
>>> > We ran heap-shot with Linux and found that in a 12 hour
>>> period it
>>> > reported this...
>>> > start:
>>> > objects: 58,823
>>> > heap memory: 6,838,426 bytes
>>> >
>>> > end:
>>> > objects: 59,925
>>> > heap memory: 6,862,336
>>> >
>>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory
>>> size
>>> > (RES) got
>>> > significantly bigger than it.
>>> >
>>> > I have searched for the Compacting GC with no luck, we would
>>> > really like
>>> > to see if it would help our problem.
>>> >
>>> > The only operating system resources we're using are
>>> Sockets, but
>>> > we use
>>> > them VERY heavily!
>>> >
>>> > If anyone has any suggestions, we'd be open to test out
>>> anything
>>> > at this
>>> > point!
>>> >
>>> > We are leaning towards an issue in unmanaged memory and
>>> possibly a bug
>>> > in mono.
>>> >
>>> > Best regards,
>>> > David
>>> >
>>> >
>>> > ps, I fwded this to gc and devel list because gc list looks
>>> quite
>>> > dead.... sorry for the duplication
>>> > _______________________________________________
>>> > Mono-devel-list mailing list
>>> > Mono-devel-list@...
>>> <mailto:Mono-devel-list@...>
>>> > <mailto:Mono-devel-list@...
>>> <mailto:Mono-devel-list@...>>
>>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>> >
>>> >
>>>
>>>
>>>
>>
>> _______________________________________________
>> Mono-gc-list maillist - Mono-gc-list@...
>> http://lists.ximian.com/mailman/listinfo/mono-gc-list
>>
>>
>
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T09:44:03Z

We've isolated the problem down to AutoResetEvent...

using System;
using System.Threading;

namespace Ipop {
public class IPOP_Common {
public static void Main() {
AutoResetEvent re = null;
while(true) {
re = new AutoResetEvent(false);
re.Close();
}
}
}
}

blows up memory

whereas ...

using System.Security.Cryptography;
using System;

namespace Ipop {
public class IPOP_Common {
public static void Main() {
RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
while(true) {
byte[] key = new byte[1024];
rng.GetBytes(key);
}
}
}
}

This doesn't.

David Wolinsky wrote:

> We run this software on system where memory is a concern. The data that
> we presented is our test case system that has 50 nodes all running in
> the same mono process. We run only a single node at each site which
> initially starts at ~15 MB, we've seen it swell to well over 300 MBs in
> a period of less than a week. Since this must be used in production
> environments and is meant to be extremely lightweight we can forgive a
> small memory portion like 15 MB, since it has relatively no processing
> overhead, but at over 300 MBs our processes are often stopped by the
> remote admin and we are told to clean up the problem.
>
> Since this seems to be a problem of using a non-compacting gc, do you
> know where the compacting gc is, so that we could at least test it out.
> I searched the SVN and found no clues of it.
>
> Also, I should correct myself, the results for memory consumption were
> not directly related to the test that grows at 25kB/sec. I found this
> out after posting the data, I am running heap-shot right now with the
> correct test and it has grown 100MB in less than 1 hour.
>
> Regards,
> David
>
>
>
> Alan McGovern wrote:
>
>> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have
>> over 1 gig of memory allocated. As you don't, i think what you're
>> seeing is just 'normal usage' for the non-compacting GC that mono
>> uses. I have a similar app which uses sockets extensively (50-150
>> simultaneous connections) and i can assure you that memory usage
>> doesn't get unbearably large. It'd be interesting to see the logs but
>> i don't think there's much to be worried about.
>>
>> Alan.
>>
>> On 7/18/07, *David Wolinsky* <davidiw@...
>> <mailto:davidiw@...>> wrote:
>>
>> Initially 45 MB, 12 hours later 147 MB
>>
>> Another developer has the heap-shot logs, I'll post those as soon as
>> possible.
>>
>> David
>>
>> Alan McGovern wrote:
>> > Could you post up the detailed stats from heapshot? After the 12
>> hour
>> > run, how much memory are you using? Are we talking in the gigabyte
>> > range, or megabyte range?
>> >
>> > Alan.
>> >
>> > On 7/18/07, *David Wolinsky* <davidiw@...
>> <mailto:davidiw@...>
>> > <mailto:davidiw@... <mailto:davidiw@...>>> wrote:
>> >
>> > My lab works on a peer-to-peer network overlay and we've noticed
>> > recently significant memory issues. Some background...
>> >
>> > This application is constantly creating new objects and shortly
>> > thereafter deleting (removing reference to) them
>> > Using a sample run with 150 threads running...
>> > Mono on Linux has a growth rate of ~25 KB per second with a
>> base
>> > of 50MB
>> > (y = 25K *x + 50M)
>> > .NET on Windows stabilizes at 35 MB
>> >
>> > We ran heap-shot with Linux and found that in a 12 hour
>> period it
>> > reported this...
>> > start:
>> > objects: 58,823
>> > heap memory: 6,838,426 bytes
>> >
>> > end:
>> > objects: 59,925
>> > heap memory: 6,862,336
>> >
>> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size
>> > (RES) got
>> > significantly bigger than it.
>> >
>> > I have searched for the Compacting GC with no luck, we would
>> > really like
>> > to see if it would help our problem.
>> >
>> > The only operating system resources we're using are Sockets, but
>> > we use
>> > them VERY heavily!
>> >
>> > If anyone has any suggestions, we'd be open to test out
>> anything
>> > at this
>> > point!
>> >
>> > We are leaning towards an issue in unmanaged memory and
>> possibly a bug
>> > in mono.
>> >
>> > Best regards,
>> > David
>> >
>> >
>> > ps, I fwded this to gc and devel list because gc list looks
>> quite
>> > dead.... sorry for the duplication
>> > _______________________________________________
>> > Mono-devel-list mailing list
>> > Mono-devel-list@...
>> <mailto:Mono-devel-list@...>
>> > <mailto:Mono-devel-list@...
>> <mailto:Mono-devel-list@...>>
>> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
>> >
>> >
>>
>>
>>
>
> _______________________________________________
> Mono-gc-list maillist - Mono-gc-list@...
> http://lists.ximian.com/mailman/listinfo/mono-gc-list
>
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T09:20:08Z

We run this software on system where memory is a concern. The data that
we presented is our test case system that has 50 nodes all running in
the same mono process. We run only a single node at each site which
initially starts at ~15 MB, we've seen it swell to well over 300 MBs in
a period of less than a week. Since this must be used in production
environments and is meant to be extremely lightweight we can forgive a
small memory portion like 15 MB, since it has relatively no processing
overhead, but at over 300 MBs our processes are often stopped by the
remote admin and we are told to clean up the problem.

Since this seems to be a problem of using a non-compacting gc, do you
know where the compacting gc is, so that we could at least test it out.
I searched the SVN and found no clues of it.

Also, I should correct myself, the results for memory consumption were
not directly related to the test that grows at 25kB/sec. I found this
out after posting the data, I am running heap-shot right now with the
correct test and it has grown 100MB in less than 1 hour.

Regards,
David

Alan McGovern wrote:

> Well, after 12 hours at a consistent 25kB/sec, you'd expect to have
> over 1 gig of memory allocated. As you don't, i think what you're
> seeing is just 'normal usage' for the non-compacting GC that mono
> uses. I have a similar app which uses sockets extensively (50-150
> simultaneous connections) and i can assure you that memory usage
> doesn't get unbearably large. It'd be interesting to see the logs but
> i don't think there's much to be worried about.
>
> Alan.
>
> On 7/18/07, *David Wolinsky* <davidiw@...
> <mailto:davidiw@...>> wrote:
>
> Initially 45 MB, 12 hours later 147 MB
>
> Another developer has the heap-shot logs, I'll post those as soon as
> possible.
>
> David
>
> Alan McGovern wrote:
> > Could you post up the detailed stats from heapshot? After the 12
> hour
> > run, how much memory are you using? Are we talking in the gigabyte
> > range, or megabyte range?
> >
> > Alan.
> >
> > On 7/18/07, *David Wolinsky* <davidiw@...
> <mailto:davidiw@...>
> > <mailto:davidiw@... <mailto:davidiw@...>>> wrote:
> >
> > My lab works on a peer-to-peer network overlay and we've noticed
> > recently significant memory issues. Some background...
> >
> > This application is constantly creating new objects and shortly
> > thereafter deleting (removing reference to) them
> > Using a sample run with 150 threads running...
> > Mono on Linux has a growth rate of ~25 KB per second with a
> base
> > of 50MB
> > (y = 25K *x + 50M)
> > .NET on Windows stabilizes at 35 MB
> >
> > We ran heap-shot with Linux and found that in a 12 hour
> period it
> > reported this...
> > start:
> > objects: 58,823
> > heap memory: 6,838,426 bytes
> >
> > end:
> > objects: 59,925
> > heap memory: 6,862,336
> >
> > We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size
> > (RES) got
> > significantly bigger than it.
> >
> > I have searched for the Compacting GC with no luck, we would
> > really like
> > to see if it would help our problem.
> >
> > The only operating system resources we're using are Sockets, but
> > we use
> > them VERY heavily!
> >
> > If anyone has any suggestions, we'd be open to test out
> anything
> > at this
> > point!
> >
> > We are leaning towards an issue in unmanaged memory and
> possibly a bug
> > in mono.
> >
> > Best regards,
> > David
> >
> >
> > ps, I fwded this to gc and devel list because gc list looks
> quite
> > dead.... sorry for the duplication
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list@...
> <mailto:Mono-devel-list@...>
> > <mailto:Mono-devel-list@...
> <mailto:Mono-devel-list@...>>
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
>
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: [Mono-dev] Mono memory problems!

2007-07-18T07:06:32Z

Initially 45 MB, 12 hours later 147 MB

Another developer has the heap-shot logs, I'll post those as soon as
possible.

David

Alan McGovern wrote:

> Could you post up the detailed stats from heapshot? After the 12 hour
> run, how much memory are you using? Are we talking in the gigabyte
> range, or megabyte range?
>
> Alan.
>
> On 7/18/07, *David Wolinsky* <davidiw@...
> <mailto:davidiw@...>> wrote:
>
> My lab works on a peer-to-peer network overlay and we've noticed
> recently significant memory issues. Some background...
>
> This application is constantly creating new objects and shortly
> thereafter deleting (removing reference to) them
> Using a sample run with 150 threads running...
> Mono on Linux has a growth rate of ~25 KB per second with a base
> of 50MB
> (y = 25K *x + 50M)
> .NET on Windows stabilizes at 35 MB
>
> We ran heap-shot with Linux and found that in a 12 hour period it
> reported this...
> start:
> objects: 58,823
> heap memory: 6,838,426 bytes
>
> end:
> objects: 59,925
> heap memory: 6,862,336
>
> We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size
> (RES) got
> significantly bigger than it.
>
> I have searched for the Compacting GC with no luck, we would
> really like
> to see if it would help our problem.
>
> The only operating system resources we're using are Sockets, but
> we use
> them VERY heavily!
>
> If anyone has any suggestions, we'd be open to test out anything
> at this
> point!
>
> We are leaning towards an issue in unmanaged memory and possibly a bug
> in mono.
>
> Best regards,
> David
>
>
> ps, I fwded this to gc and devel list because gc list looks quite
> dead.... sorry for the duplication
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@...
> <mailto:Mono-devel-list@...>
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Mono memory problems!

2007-07-18T06:08:51Z

My lab works on a peer-to-peer network overlay and we've noticed
recently significant memory issues. Some background...

This application is constantly creating new objects and shortly
thereafter deleting (removing reference to) them
Using a sample run with 150 threads running...
Mono on Linux has a growth rate of ~25 KB per second with a base of 50MB
(y = 25K *x + 50M)
.NET on Windows stabilizes at 35 MB

We ran heap-shot with Linux and found that in a 12 hour period it
reported this...
start:
objects: 58,823
heap memory: 6,838,426 bytes

end:
objects: 59,925
heap memory: 6,862,336

We have run mono with GC_MAXIMUM_HEAP_SIZE and the memory size (RES) got
significantly bigger than it.

I have searched for the Compacting GC with no luck, we would really like
to see if it would help our problem.

The only operating system resources we're using are Sockets, but we use
them VERY heavily!

If anyone has any suggestions, we'd be open to test out anything at this
point!

We are leaning towards an issue in unmanaged memory and possibly a bug
in mono.

Best regards,
David

ps, I fwded this to gc and devel list because gc list looks quite
dead.... sorry for the duplication
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Mono memory problems!

2007-07-17T23:08:29Z

Request for backport of garbage collection patch

2007-07-17T17:54:34Z

Hi -

I'm working on improving mono-under-wine (on the wine side), and I've
been hitting a bug in the mono garbage collector fixed by commit
#77073 ([1]). The bug in question is a race condition between
GetExitCodeThread and SuspendThread - if a thread terminates between
the two, SuspendThread will fail. The race condition is pretty
reliably triggered by the regression test suite when running under
wine.

The current patch could actually be reduced further (the
GetExitCodeThread block could be fully deleted, as it is rendered
redundant), but it works as is.

Any chance this patch could be applied to the maintenance branch? The
patch applies cleanly to 1.13.8.2.

Thank you very much,
-Matt Jones

[1] http://anonsvn.mono-project.com/viewcvs/trunk/mono/libgc/win32_threads.c?rev=77073&view=log
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Re: Tracing GC operations

2007-06-11T09:19:37Z

On 06/08/07 Matt Jones wrote:
> I'm trying to hunt down a threading bug in wine that shows up when some of
> the unit tests from mono are run under wine (so using a windows version of
> mono). The bug shows up during the GC collect cycle (the function is gc_push
> or something like that). It's not a bug in mono per se, but being able to
> trace the operation of the gc would make figuring out what's going on much
> easier. Is there any good tracing facility for this? I've tried "mono
> --trace=System.GC", but I don't get anything out.

That will trace only the calls to the managed methods in the GC class.
Setting the env vars GC_DUMP_REGULARLY and GC_PRINT_STATS will generate
GC logging information, though I'm not sure it would be useful in your
case. Likely getting the crash to happen while under gdb and poking
around can be more useful.

> Also, is there any way to control the operation of the GC (such as forcing a
> full pass at a pre-determined time etc.). Part of the problem with the bug
> I'm trying to hunt down is that it occurs very rarely (unsurprising as its
> likely to do with wine's handling of threading), so coming up with a better
> way than running the tests until the bug occurs would be awesome.

That's not possible without adding specific code to the GC and
recompiling.
You may also want to repost to mono-devel where people that use windows
are more likely to read your email and maybe help more.

lupus

--
-----------------------------------------------------------------
lupus@... debian/rules
lupus@... Monkeys do it better
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Tracing GC operations

2007-06-08T15:54:05Z

Hi -

I'm trying to hunt down a threading bug in wine that shows up when some of the unit tests from mono are run under wine (so using a windows version of mono). The bug shows up during the GC collect cycle (the function is gc_push or something like that). It's not a bug in mono per se, but being able to trace the operation of the gc would make figuring out what's going on much easier. Is there any good tracing facility for this? I've tried "mono --trace= System.GC", but I don't get anything out.

Also, is there any way to control the operation of the GC (such as forcing a full pass at a pre-determined time etc.). Part of the problem with the bug I'm trying to hunt down is that it occurs very rarely (unsurprising as its likely to do with wine's handling of threading), so coming up with a better way than running the tests until the bug occurs would be awesome.

Thanks,
Matt Jones

_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list

Calling Unmanaged dll from C#

2006-06-19T08:03:20Z

Hi All,

I want to use DllImport to call a C function that allocates and
returns an array of strings. I'm not sure if this is the right place
to ask this question, but my sample code works with windows .NET
compiler, so either there is a different way to call unmanaged dlls in
mono or may be i'm not implementing it right?

I've a C function that converts a char * to wchar_t *

DllExport Func(wchar_t** ipadds)
{
char mbBuf[BUF_SIZE] = "1.1.1.1";
char* s = mbBuf;
size_t len = strlen (mbBuf);
wchar_t *result = malloc ((len + 1) * sizeof (wchar_t));
wchar_t *wcp = result;
wchar_t tmp;
mbstate_t state;
size_t nbytes;

int i = 0;
memset (&state, '\0', sizeof (state));
while ((nbytes = mbrtowc (&tmp, s, len, &state)) > 0)
{
if (nbytes >= (size_t) -2)
/* Invalid input string. */
return NULL;

result[i] = tmp;
i++;
len -= nbytes;
s += nbytes;
}

result[i] = '\0';
*ipadds = result;
}

My C# code looks like this:

[DllImport("KeyServerUsage.dll", CharSet = CharSet.Auto,
EntryPoint = "Func")]
private static extern void Func([Out] string[] Names);

public ArrayList GetIPAdd()
{
string[] ipadds = new string[2];
Func(ipadds);
}

Now i get a blank array returned in ipadds when i run this program
with mono. But when i run the same program on windows, i get "1.1.1.1"
in ipadds[0]. Any help would be greatly appreciated. BTW I have the
same question posted on mono-devel mailing list too.

Thanks,
Romy
_______________________________________________
Mono-gc-list maillist - Mono-gc-list@...
http://lists.ximian.com/mailman/listinfo/mono-gc-list