Shared Libraries and Thread Creation

Fri Dec 9 12:14:00 GMT 2005

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.