This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Shared Libraries and Thread Creation
- From: Andrew Haley <aph at redhat dot com>
- To: "Craig A. Vanderborgh" <craigv at voxware dot com>
- Cc: java at gcc dot gnu dot org
- Date: Fri, 9 Dec 2005 12:14:41 +0000
- Subject: Re: Shared Libraries and Thread Creation
- References: <4398BC3C.3010802@voxware.com>
Craig A. Vanderborgh writes:
> Hello Everyone:
>
> I am doing some research on using shared libraries w/GCJ 4.1 on x86,
> RHEL 4 (kernel 2.6.9-5.EL, uniprocessor)
>
> I am seeing memory use patterns in top/ps from my test programs that I
> simply do not understand. It seems that if I have a dynamically linked
> GCJ program (w/libgcj.so, libc.so, libstdc++.so) the cost of thread
> creation in terms of memory use is MUCH, MUCH higher than the same
> program statically linked.
>
> As one example, consider my lovely "PauseWorld" program:
>
> class PauseWorld {
> public static void main(String[] args) {
> System.out.println("Pause World from GCJ!");
> try {
> Thread.sleep(1000000000);
> } catch (Exception e) {
> }
> }
> }
>
> If this program is statically linked, its process when run has a 12180M
> VSZ, and a 3536 RSS. When everything else is the same and the program
> is linked with shared libraries, it has a 23840 VSZ and a 6592 RSS.
>
> When viewed via strace, the "clone" call for the static case looks like
> this:
>
> clone(child_stack=0x84d5b88,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND) = 1544
>
> versus the dynamically-linked case:
>
> clone(child_stack=0x19c84c8,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED,
> parent_tidptr=0x19c8bf8, {entry_number:6, base_addr:0x19c8bb0,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0x19c8bf8)
> = 21035
>
> Why on earth would thread creation in the dynamically linked case
> consume so much more system memory (VSZ)?? Or does it? Are the numbers
> being reported via top/ps misleading for some reason I do not understand?
>
> Why would the dynamically linked version of this puny test require twice
> as much memory to run dynamically linked as it does statically? And
> note - I have been able to observe (with the help of gdb) that it is THE
> ACT OF THREAD CREATION with the dynamically linked test program that
> causes the memory use to skyrocket!
Simply looking at memory size totals can be quite misleading.
Have a look at proc/<pid>/maps to see what the memory allocation
really is.
Andrew.