From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FKZnF-00033p-K5 for garchives@archives.gentoo.org; Sat, 18 Mar 2006 11:40:26 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5.20060308/8.13.5) with SMTP id k2IBdOwu029504; Sat, 18 Mar 2006 11:39:24 GMT Received: from ch.its.tudelft.nl (ch.its.tudelft.nl [130.161.156.139]) by robin.gentoo.org (8.13.5.20060308/8.13.5) with ESMTP id k2IBdORJ016851 for ; Sat, 18 Mar 2006 11:39:24 GMT Received: from localhost ([127.0.0.1] helo=ch.its.tudelft.nl) by ch.its.tudelft.nl with esmtp (Exim 4.50) id 1FKZmD-0005kV-7S for gentoo-java@lists.gentoo.org; Sat, 18 Mar 2006 12:39:21 +0100 Received: from sebastia (helo=localhost) by ch.its.tudelft.nl with local-esmtp (Exim 4.50) id 1FKZmD-0005kS-3a for gentoo-java@lists.gentoo.org; Sat, 18 Mar 2006 12:39:21 +0100 Date: Sat, 18 Mar 2006 12:39:21 +0100 (CET) From: Sebastiaan To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] java.lang.OutOfMemoryError on amd64 In-Reply-To: <441B31A5.9080407@gentoo.org> Message-ID: References: <441B31A5.9080407@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1585280100-835630511-1142681961=:21900" X-CH-MailScanner-VirusCheck: Found to be clean X-MailScanner-From: sebastia@ch.its.tudelft.nl X-Archives-Salt: 31f36519-a962-4f60-b4d1-25e3ffed3f60 X-Archives-Hash: 69a6da0d227f8675ba6dcdeaebd678b6 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1585280100-835630511-1142681961=:21900 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi! On Fri, 17 Mar 2006, Joshua Nichols wrote: > Whoops... accidentally replied off list much earlier today. > > Sebastiaan wrote: >> I have tried to increase the amount of memory java can use by adding=20 >> -J-Xms48m to the command (right after configuration, since a second=20 >> compilation attempt always works), but without succes. >>=20 > -Xms sets the initial memory allocated. You probably want -Xmx, which set= s=20 > the maximum amount of memory that will be allocated, and you probably wan= t=20 > this to be fairly high, or at least more than 48m. > If you're going to patch the makefiles, a clean way to do it may be to ad= d=20 > like a variable JAVACFLAGS, which we can then set in the ebuild like: > use amd64 && JAVACFLAGS=3D"-J-Xmx256m ${JAVACFLAGS}" Yes! This works. >> Does anyone have an idea what the problem can be? I am unsure if the=20 >> problem lies within VTK or Blackdown. Sun-jdk does not have a 64 bit=20 >> version available, so I cannot compare with that. >>=20 > I'm pretty sure it's a blackdown on amd64 thing. We do encounter it for a= few=20 > packages, like net-p2p/azureus. For the record, there is a amd64 version = of=20 > sun-jdk-1.5 (and 1.6...), but I'm sure at this point I shouldn't have to = go=20 > into the concerns about using them ;) > I am still a little bit disfigured: is the problem is the amount of=20 allocated memory, why does a second make always work? Perhaps javac is=20 keeping some cache? Thanks! Sebastiaan >> References: >> I have previously posted this to=20 >> http://bugs.gentoo.org/show_bug.cgi?id=3D123178 as well. >>=20 > > Hope this helps, > - Josh > -- English written by Dutch people is easily recognized by the improper use of= 'In principle ...' The software box said 'Requires Windows 95 or better', so I installed Linux= =2E Als Pacman in de jaren '80 de kinderen zo had be=EFnvloed zouden nu veel jo= ngeren rondrennen=20 in donkere zalen terwijl ze pillen eten en luisteren naar monotone electron= ische muziek.=20 (Kristian Wilson, Nintendo, 1989) ---1585280100-835630511-1142681961=:21900-- -- gentoo-java@gentoo.org mailing list