2:16 a.m.
Open the scratch scratch buffer, evaluate stuff below
and monitor xemacs virtual memory (committed, private) size.
My numbers are below.
Start, Mem. usage = 8M
(make-string 10000000 ?A) ->> 18M
; After ~1s, the string displayed in the minibuffer ->> 55M
(garbage-collect) ->> 55M
(make-string 10000000 ?B) ->> 80M
(garbage-collect) ->> 70M
(make-string 10000000 ?C) ->> 80M
(garbage-collect) ->> 70M ; Well, looks stable but...
(make-string 10000000 ?D) ->> 80M
(make-string 10000000 ?E) ->> 100M
(make-string 10000000 ?F) ->> 125M
(make-string 10000000 ?G) ->> 150M
(make-string 10000000 ?H) ->> 165M
(make-string 10000000 ?I) ->> 168M
(garbage-collect) ->> 151M
Bye bye 150 MB....
Looks like it has to do with minibuffer printing. I'll try
to build xemacs with native NT allocator, run it from temacs
(it won't be dumpable) and see if there is any difference.
Please test this under different platforms.
Big K
4:59 a.m.
Ok, I tested it with the NT allocator. There is a memory leakage,
but it's different. Anybody knows what's that?
New figures are in parenteses.
Start, Mem. usage = 8M
(make-string 10000000 ?A) ->> 18M (18M)
; After ~1s, the string displayed in the minibuffer ->> 55M (38M)
(garbage-collect) ->> 55M (28M)
(make-string 10000000 ?B) ->> 80M (46M)
(garbage-collect) ->> 70M (28M)
(make-string 10000000 ?C) ->> 80M (46M)
(garbage-collect) ->> 70M (25M) ; Well, looks stable but...
(make-string 10000000 ?D) ->> 80M (45M)
(make-string 10000000 ?E) ->> 100M (64M)
(make-string 10000000 ?F) ->> 125M (84M)
(make-string 10000000 ?G) ->> 150M (103M)
(make-string 10000000 ?H) ->> 165M (123M)
(make-string 10000000 ?I) ->> 168M (143M)
(garbage-collect) ->> 151M (25M)
Bye bye 150 MB....
This time I kissed goodbye "only" 17 meg. Whassup?
Big K
9:47 a.m.
Kirill 'Big K' Katsnelson writes:
Ok, I tested it with the NT allocator. There is a memory leakage,
but it's different. Anybody knows what's that?
This is probably not a memory leak. Under UNIX you can't always
give memory back to the system, either because malloc() doens't
know that the memory it is all freed or because malloc() doesn't
know all the pointers that point to a block of used memory so
that relocation can be done. Test results vary depending on how
clever malloc() is.
7:32 a.m.
Some time ago, Kyle Jones wrote...
Kirill 'Big K' Katsnelson writes:
> Ok, I tested it with the NT allocator. There is a memory leakage,
> but it's different. Anybody knows what's that?
This is probably not a memory leak. Under UNIX you can't always
give memory back to the system, either because malloc() doens't
know that the memory it is all freed or because malloc() doesn't
know all the pointers that point to a block of used memory so
that relocation can be done. Test results vary depending on how
clever malloc() is.
That was what I thought in the first place, this is why I re-tested
it under NT allocator. I understand that malloc'ed memory cannot
be moved, and that free shots holes which could not always be reused,
when requested new allocation does not fit into any hole, in which
case sbrk is used to extend the heap.
Now it looks like any of the two (or both in the worst case) lose:
either emulated sbrk() in XEmacs (it is in ntheap.c, there is no
real one), or the galloc allocator.
My test is kind of artificial, but it shows that there can be
conditions under which XEmacs tends to devour memory indefinitely.
I just want to be sure that if the cause of the problem is the
gnu allocator, then it will be fixed.
One possible enhancement to the allocation scheme is to allocate
very large blocks of memory using system virtual memory allocator.
Regular heap managers are not designed for whopping big memory blocks.
Big K
10:22 a.m.
>>>> "kkm" == Kirill 'Big K' Katsnelson
<kkm(a)dtmx.com> writes:
kkm> Ok, I tested it with the NT allocator. There is a memory leakage,
kkm> but it's different. Anybody knows what's that?
kkm> New figures are in parenteses.
Solaris 2.6 Purify says `No memory leak.'
Does the memory leak `go away' if you run another memory hog program
that allocates all the memory it can?
main() { while (malloc (1024 * 1024)); } /* Untested :) */
Martin
8:13 p.m.
Martin Buchholz <martin(a)xemacs.org> wrote:
Solaris 2.6 Purify says `No memory leak.'
Purify under Solaris is pretty good. If purify says there isn't a
memory leak, there probably isn't one.
Umm, could this be a case of the message-log just keeping copies of
the HUGE messages?
--
Darryl Okahata
darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
8995
days inactive
8996
days old
5 comments
4 participants
participants (4)
-
Darryl Okahata -
Kirill 'Big K' Katsnelson -
Kyle Jones -
Martin Buchholz