------- Comment #4 from rob1weld at aol dot com  2009-01-12 12:47 -------
(In reply to comment #3)
> With 1400M (and 512M swap) it dies here:
>... 
> -g -O2 -m64 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF
> classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip 
> -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o
> jc1: out of memory allocating 4072 bytes after a total of 380526592 bytes
> gmake[5]: *** [classpath/tools/libgcj_tools_la-tools.lo] Error 1
> gmake[5]: Leaving directory
> `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava'
> gmake[4]: *** [all-recursive] Error 1
> gmake[4]: Leaving directory
> `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava'
> gmake[3]: *** [multi-do] Error 1
> gmake[3]: Leaving directory
> `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava'
> gmake[2]: *** [all-multi] Error 2
> gmake[2]: Leaving directory
> `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava'
> gmake[1]: *** [all-target-libjava] Error 2
> gmake[1]: Leaving directory `/usr/share/src/gcc_build'
> gmake: *** [all] Error 2


I increased my memory to 1900MB (to leave 1G for WinXP) in VirtualBox
but it crashed soonafter complaining that WinXP had too little memory.
I decreased to 1800MB and tried again, VirtualBox is stable now.

When running the build I watched the "System Performance Monitor" and 
monitored the amount of memory used. 

With the ./configure options I am using
"gnu/javax/swing/text/html/parser/.libs/HTML_401F.o"
was the least of our problems. Compiling
"classpath/tools/.libs/libgcj_tools_la-tools.o"
takes up a much greater amount of memory (as does another section shortly after 
"HTML_401F.o".


# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc_trunk/configure
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared
--disable-static --enable-decimal-float --with-long-double-128 --enable-nls
--with-included-gettext --enable-gather-detailed-mem-stats --with-stabs
--enable-debug -enable-largefile --enable-symvers --without-system-zlib
--enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer
--enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug
--enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug
--disable-stage1-checking --enable-checking=release --without-system-libunwind
--with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld
--with-ld=/usr/local/bin/ld
Thread model: posix
gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] (GCC) 


The final result is that on OpenSolaris 2008.11 with 512M of swap you
__MUST__ HAVE A MINIMUM of 1750M to compile gcc rev. 143259 (if you use
the same options that I did). More is always better but I doubt you can
go over 1850MB without VirtualBox becoming unstable.


This is a problem from a standpoint of performance of the build (speed)
and the restriction of some peoples ability to build the Toolchain on
some Platforms. We can just barely compile gcc because of a couple of 
humps (under certain conditions).

Last I checked we were a few versions behind in our Boehm and there
were issues dropping the newest rev. into the dirs due to Java, fixed?

Thanks,
Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |memory-hog


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717

Reply via email to