Is it a 64bits machine?
If so, the same is true for us.
But, with 32 bits mono, we can consistently repeat the issue. I can set
up a gotomeeting and show you how it happens.
pablo
Zoltan Varga wrote:
Hi,
On my machine, after the allocation of the 2.5GB of arrays + 10 gcs,
the
Hi Zoltan,
Let me point some data from our tests to the discussion.
I think it's not so normal, if you allocate 2.5GB of arrays, after 10
gcs you'd have 2.5GB virtual, but RSS should go down to a few mb (10,
20) if gc works fine. This is because GC removes all permissions from
all the big
On Wed, 2009-09-30 at 10:24 +0200, David Suarez wrote:
Hi Zoltan,
Let me point some data from our tests to the discussion.
Those blocks up to 100Mb are actually leaked I'm afraid. If you do
again the same operation in the sample (allocate 2.5GB), your virt
memory will again go up to
On Mon, Sep 28, 2009 at 11:41 PM, Miguel de Icaza mig...@novell.com wrote:
The problem with AppDomains is that upon unloading there is a potential
for leaking vtables, something that I do not particular think is as
important as being able to scan the AppDomains precisely.
This is one of the
Hi Miguel,
Hello,
I tried your sample, in my machine the memory usage with Case1 does
go up very quickly, but then it tends to stay stable around 600 megs.
Ok, but the problem is that ALL memory should be freed, since there are
no references to the arrays. Of course you've to
On Mon, 2009-09-28 at 17:41 -0400, Miguel de Icaza wrote:
Hello,
Libgc supports this kind of descriptors and mono already generates
them
for the sgen gc, so it's just a matter of joining those together
(which
should beeasy to do). This should improve a great number of scans in
the
Hi,
mono uses the GC_GCJ_MALLOC family of functions which take a gc
descriptor.
Zoltan
On Tue, Sep 29, 2009 at 6:08 PM, Dick Porter dpor...@codicesoftware.comwrote:
On Mon, 2009-09-28 at 17:41 -0400, Miguel de Icaza wrote:
Hello,
Libgc supports this kind of descriptors
Hello,
Ok, but the problem is that ALL memory should be freed, since there
are no references to the arrays. Of course you've to invoke GC. The
600Mb in RES is a leak (Virtual Mem will only grow since libgc will
never release it, this is another patch Dick has been working on)
This can
Ok, but the problem is that ALL memory should be freed, since there
are no references to the arrays. Of course you've to invoke GC. The
600Mb in RES is a leak (Virtual Mem will only grow since libgc will
never release it, this is another patch Dick has been working on)
This can easily be
Hello,
On Mon, Sep 28, 2009 at 11:41 PM, Miguel de Icaza mig...@novell.com wrote:
The problem with AppDomains is that upon unloading there is a potential
for leaking vtables, something that I do not particular think is as
important as being able to scan the AppDomains precisely.
This is
Hi,
You can run with
MONO_DEBUG=dont-free-domains
to allow typed allocation in the non-root domain when using boehm gc.
Zoltan
On Tue, Sep 29, 2009 at 8:28 PM, Miguel de Icaza mig...@novell.com wrote:
Hello,
On Mon, Sep 28, 2009 at 11:41 PM, Miguel de Icaza mig...@novell.com
On Tue, Sep 29, 2009 at 8:28 PM, Miguel de Icaza mig...@novell.com wrote:
I am not sure I understand from the description above how would leaking
the vtables kill SGen.
The problem is not leaking VTables, but leaking objects across
domains, i.e. having references from objects in one domain to
Hello,
I am not sure I understand from the description above how would leaking
the vtables kill SGen.
The problem is not leaking VTables, but leaking objects across
domains, i.e. having references from objects in one domain to objects
in another domain. Once that domain is gone, so are
Hi,
On my machine, after the allocation of the 2.5GB of arrays + 10 gcs, the
RSS of the
process goes back to about 100MB. This is perfectly normal, as the GC
doesn't return
free memory to the OS in some cases, so it doesn't have to allocate it again
when the
program starts allocating memory.
Hi all,
After several weeks working on a bunch of mem issues related to the
libgc based garbage collector, we've identified the following issue and
a possible solution (Dick already sent some workarounds to the list):
The libgc garbage collector has a really hard time identifying pointers
to
Hello,
Libgc supports this kind of descriptors and mono already generates
them
for the sgen gc, so it's just a matter of joining those together
(which
should beeasy to do). This should improve a great number of scans in
the
arking process, leaving only stacks and several minor objects
Hello,
I tried your sample, in my machine the memory usage with Case1 does
go up very quickly, but then it tends to stay stable around 600 megs.
Later, I modified the program to not allocate 1 meg blocks, but
instead to allocation 1024 times 1k blocks (so that it allocates the
same
17 matches
Mail list logo
