------- Comment #9 from rob1weld at aol dot com 2009-01-22 16:03 ------- Created an attachment (id=17162) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17162&action=view) Screenshot of build shows libgcj_tools building (after patch from 38924)
Description of the Screenshot: At the far left is a tiny blip (in the "Memory and Swap History" Display) that shows the memory usage of "gnu/javax/swing/text/html/parser/.libs/HTML_401F.o" has been _very_ strongly reduced. A _short_ distance to the right are _two_ humps that represent the 32 and 64 bit portions of linking the ".libs/libgcj-tools.so.10.0.0" libraries. Notice that this time the 64 bit library actually takes up _slightly_ _less_ memory than the linking of the 32 bit library as opposed to it's previous operation without the patch (and it is nowhere close to bringing the OS to it's knees). Finally to the far right we see the build complete successfully. Notice that the red line (indicates cache usage) shows only about 50M used. The "workaround" from the other post has an enormous effect towards alleviating the memory hogging. It seems like we might be trying to get collect to drive 'ld' in a (italics) "--enable-intermodule" (end-italics) (IE: not using, but 'sort of' equivalent to the principle of) manner. Please would a gcc/binutils Guru comment for us? Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
