From owner-freebsd-java@FreeBSD.ORG Fri Feb 6 05:40:34 2004 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A7216A4CE for ; Fri, 6 Feb 2004 05:40:34 -0800 (PST) Received: from phantom.cris.net (phantom.cris.net [212.110.130.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9532043D1D for ; Fri, 6 Feb 2004 05:40:04 -0800 (PST) (envelope-from phantom@FreeBSD.org.ua) Received: from phantom.cris.net (phantom@localhost [127.0.0.1]) by phantom.cris.net (8.12.10/8.12.10) with ESMTP id i16Dewoh030288; Fri, 6 Feb 2004 15:40:58 +0200 (EET) (envelope-from phantom@FreeBSD.org.ua) Received: (from phantom@localhost) by phantom.cris.net (8.12.10/8.12.10/Submit) id i16DewUw030287; Fri, 6 Feb 2004 15:40:58 +0200 (EET) (envelope-from phantom) Date: Fri, 6 Feb 2004 15:40:58 +0200 From: Alexey Zelkin To: Nick Barnes Message-ID: <20040206134058.GA29887@phantom.cris.net> References: <20040205233233.GA23899@phantom.cris.net> <67371.1076068441@thrush.ravenbrook.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67371.1076068441@thrush.ravenbrook.com> X-Operating-System: FreeBSD 4.9-STABLE i386 User-Agent: Mutt/1.5.5.1i cc: mps-staff@ravenbrook.com cc: freebsd-java@freebsd.org Subject: Re: JDK garbage collector: thread context scanning X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2004 13:40:34 -0000 hi, On Fri, Feb 06, 2004 at 11:54:01AM +0000, Nick Barnes wrote: > At 2004-02-05 23:32:33+0000, Alexey Zelkin writes: > > > Since JDK 1.4.1 we got correctly working fallbacks, so I was not > > required to do a black magic anymore. > > Can you enlarge on this? What are "correctly working fallbacks"? It means that if callback (used in pthread_kill()/sighandler()) schema does not return meaningful value (i.e. NULL) then JVM tries to detect this value with own way. It is slower solution, but works for us in all cases (both -STABLE and -CURRENT with any thread libraries) > > Lately I have implemented pthread_attr_get_np() function which > > exported all required information on application level and we stoped > > to use private libc_r structures in JDK 1.4.x > > Which information delivered by pthread_attr_get_np() do you use? > pthread_attr_getstack()? Kind of. But with one small, but important exception. pthread_attr_getstack() returns stackaddr and stacksize values from pthread_attr structure associated with thread. But in case if you call pthread_create() with default attribute then stackaddr will be NULL. In this case libc_r will allocate stack for this thread internally and will not export this stack pointer address into application. Usually there's no need to do it -- if application want to know location of thread stack it simply mallocs it and provide its address via pthread_attr structure to pthread_create(). Initially I did it in way just described, but lately I found that JVM does not provide way to deallocate stack after thread finishes. I had to implement own deallocating schema via separate thread almost line-by-line similar to libc_r's gc thread. Another issue with this way -- JVM provides some restriction of amount of memory to be used (via command line switches) and in case if this value was too small -- thread stack were able to eat all available memory for application itself. Of course it was possible to implement it in another way and don't eat applications' memory, but it was even more hackish than described in first item. So, implementation of pthread_attr_get_np() with current behavior allowed me to avoid implementing these hack "solutions". > > Sorry for not saying anything helpful for you :( > > Not at all, this is very helpful. > > Nick Barnes > Ravenbrook Limited -- /* Alexey Zelkin && Independent Contractor */ /* phantom(at)FreeBSD.org && http://www.FreeBSD.org/java */ /* phantom(at)cris.net && http://www.FreeBSD.org.ua/ */