From owner-freebsd-java@FreeBSD.ORG Wed Mar 7 19:54:24 2007 Return-Path: X-Original-To: freebsd-java@freebsd.org Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7624316A402 for ; Wed, 7 Mar 2007 19:54:24 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from mail1.intricatesoftware.com (static-64-115-215-92.isp.broadviewnet.net [64.115.215.92]) by mx1.freebsd.org (Postfix) with ESMTP id AC9D113C428 for ; Wed, 7 Mar 2007 19:54:23 +0000 (UTC) (envelope-from lists@intricatesoftware.com) Received: from seraph.intricatesoftware.com (relay@localhost.intricatesoftware.com [IPv6:::1]) by mail1.intricatesoftware.com (8.13.8/8.13.4) with ESMTP id l27Js96H022909; Wed, 7 Mar 2007 14:54:13 -0500 (EST) Received: from localhost.intricatesoftware.com (truk@localhost.intricatesoftware.com [127.0.0.1]) by seraph.intricatesoftware.com (8.14.0/8.14.0) with ESMTP id l27Js3La016126; Wed, 7 Mar 2007 14:54:03 -0500 (EST) From: Kurt Miller To: freebsd-java@freebsd.org Date: Wed, 7 Mar 2007 14:54:02 -0500 User-Agent: KMail/1.9.6 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200703071454.02785.lists@intricatesoftware.com> X-SMTP-Vilter-Version: 1.3.4 X-SMTP-Vilter-Virus-Backend: clamd X-SMTP-Vilter-Status: clean X-SMTP-Vilter-clamd-Virus-Status: clean X-Spamd-Symbols: ALL_TRUSTED,SPF_HELO_PASS X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Score: -1.4 X-Spam-Threshold: 5.0 X-Spam-Probability: -0.3 X-Its-A-Nuisance: This is spam X-SMTP-Vilter-Unwanted-Backend: attachment X-SMTP-Vilter-attachment-Unwanted-Status: clean Cc: "Arne H. Juul" Subject: Re: patch: autoadjust datasegment size X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kurt@intricatesoftware.com List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2007 19:54:24 -0000 Hi Arne, Some comments inline... On Thursday 22 February 2007 3:53:25 pm Arne H. Juul wrote: > We're running in an environment where the default datasegment size is > often adjusted upwards to provide more address space for applications that > allocate a lot of memory, but this causes the Java VM to fail during > startup since the Java heap is allocated outside the data segment by using > mmap(). I've been compiling with a patch (below) that auto-adjusts the > datasegment down to a "reasonable" value. > > I don't know enough about the details of the VM system of the various BSDs > to be certain that this is generally applicable, but my guess is that this > will be useful on all 32-bit BSDs. > > - Arne H. J. > > diff -ru jdk-1_5_0_11.b4/hotspot/src/os/bsd/vm/os_bsd.cpp jdk-1_5_0_11.ahj12/hotspot/src/os/bsd/vm/os_bsd.cpp > --- jdk-1_5_0_11.b4/hotspot/src/os/bsd/vm/os_bsd.cpp Sun Feb 18 16:13:42 2007 > +++ jdk-1_5_0_11.ahj12/hotspot/src/os/bsd/vm/os_bsd.cpp Tue Feb 20 22:29:27 2007 > @@ -2706,7 +2833,30 @@ > > // this is called _after_ the global arguments have been parsed > jint os::init_2(void) { > - > + > + // XXX ugly hack for 32-bit address space, since we know the > + // java heap is allocated with mmap() not sbrk(): > +#if SSIZE_MAX == 0x7fffffff On OpenBSD mmap is constrained by RLIMIT_DATA too. Not sure about NetBSD though. I think the _LP64 define is the more common way to check for 64bit vs 32bit: #if !defined(__OpenBSD__) && !defined(_LP64) > + // set the max datasegment size to something reasonable > + // complain if getrlimit/setrlimit fails but continue regardless. > + struct rlimit dseg_size; > + int status = getrlimit(RLIMIT_DATA, &dseg_size); > + if (status != 0) { > + if (PrintMiscellaneous && (Verbose || WizardMode)) > + perror("os::init_2 getrlimit failed"); > + } else { > + if (dseg_size.rlim_max > 1000 * 1024 * 1024) { > + dseg_size.rlim_max = 500 * 1024 * 1024; > + dseg_size.rlim_cur = 500 * 1024 * 1024; Some spot checking on 6.1 revealed that data seg size could be increased to slightly above 800M before interfeering with the jvm. I think it would be better if this was constrained by 800M instead of 1G and if > 800M then set to 800M. > + status = setrlimit(RLIMIT_DATA, &dseg_size); > + if (status != 0) { > + if (PrintMiscellaneous && (Verbose || WizardMode)) > + perror("os::init_2 setrlimit failed"); > + } > + } > + } > +#endif > + > // Allocate a single page and mark it as readable for safepoint polling > if( SafepointPolling ) { > address polling_page = (address) ::mmap(NULL, page_size, > _______________________________________________ > freebsd-java@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-java > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" >