[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Memory allocation jump after running for a while with a largenumber of threads

No, it's SUN JDK 1.4.1 running on top of 2.5.60 + latest NPTL
bits on rawhide (Hrvoje?). So the entire thread stack and
its guard pages are map'ed upfront when the thread is first
created. Real Java stacks are mmap'ed at lower address space
as groups of 4+52+12+60 memory regions:

5bc80000 (4 KB)        ---p (00:00 0)   // libc stack guard
5bc81000 (52 KB)       rwxp (00:00 0)   // signal stack
5bc8e000 (12 KB)       ---p (00:00 0)   // VM stack guards
5bc91000 (60 KB)       rwxp (00:00 0)   // thread stack
5bda0000 (4 KB)        ---p (00:00 0)
5bda1000 (52 KB)       rwxp (00:00 0)
5bdae000 (12 KB)       rwxp (00:00 0)
5bdb1000 (60 KB)       rwxp (00:00 0)

(I don't want to polute the mailing list with huge memory dumps,
but if you are interested, drop me an email and I'll forward it
to you)


Hong Zhang wrote:
These memory blocks are clearly java stack. The 32KB are used
for thread, the 992KB are stack lazy expanded. I can bet this
is IBM JVM. The problem you have is probably caused by some
jvm algorithm used for stack management.

The most common scheme is to use large stack for first xxx
number of thread, and use smaller stack for the rest. The
number you gave is not insane in this context.


-----Original Message-----
From: Ulrich Drepper [mailto:drepper redhat com]
Sent: Wednesday, February 19, 2003 12:43 AM
To: phil-list redhat com
Subject: Re: Memory allocation jump after running for a while with a
large number of threads

Hui Huang wrote:

bdf00000 (32 KB)       rw-p (00:00 0)
bdf08000 (992 KB)      ---p (00:00 0)
be100000 (32 KB)       rw-p (00:00 0)
be108000 (992 KB)      ---p (00:00 0)
be300000 (32 KB)       rw-p (00:00 0)
be308000 (992 KB)      ---p (00:00 0)
be500000 (32 KB)       rw-p (00:00 0)
be508000 (992 KB)      ---p (00:00 0)
be700000 (32 KB)       rw-p (00:00 0)
be708000 (992 KB)      ---p (00:00 0)

The permission would indicate it's used for the stack guard. Does the
JVM set a stack guard size? I'll take a look to see whether there can
be a reason for using such a guard size (note: 992 + 32 = 1024). Maybe
some kind of overflow.

--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------

Phil-list mailing list
Phil-list redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]