Installing libgcj consumes huge amounts of memory

Mon Dec 12 11:43:00 GMT 2005

Mark Wielaard writes:
 > Hi Gerald,
 > 
 > On Mon, 2005年12月12日 at 00:21 +0100, Gerald Pfeifer wrote:
 > > On Sun, 4 Dec 2005, Mark Wielaard wrote:
 > > >> 2005年09月21日 Mark Wielaard <mark@klomp.org>
 > > >> 
 > > >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep.
 > > > I reversed this (patch attached) and now my build with ulimit -v450000
 > > > passes. But the total virtual memory usage didn't drop that much. It was
 > > > around 454MB top usage, to 438MB top usage. Build time increased with
 > > > several minutes. Maybe this was just the tipping point for your setup?
 > > 
 > > Is it possible that the last Classpath imports caused this to break for
 > > me (and others), since we added some new modules?
 > 
 > Yes, I think that is what happened since GNU Classpath added a lot of
 > new standard library code in the last couple of months (those evil
 > productive hackers...). The particular make file dependency generator
 > was part of the code for a much longer time.
 > 
 > > Is there any other way to address the problem during installation? 
 > > Perhaps by splitting the package set into two partitions and processing 
 > > these separately or something along these lines?
 > 
 > I hope so, but I admit to not have a real plan yet. But I just setup an
 > auto-builder for GNU Classpath and cannot test it against gcc trunk
 > because of the same reason (it is a Xen instance with access to "only"
 > 512MB of main memory) so it just moved up on my must fix list.
Well, as hj has found the problem in make and produced something of a
workaround, we should perhaps concentrate our efforts in that
direction.
I'm not saying we shouldn't split the package set, if it is really
useful.
Andrew.