From owner-freebsd-java@FreeBSD.ORG Tue Feb 8 01:28:14 2011 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DA671065673; Tue, 8 Feb 2011 01:28:14 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id D3EA68FC15; Tue, 8 Feb 2011 01:28:13 +0000 (UTC) Received: from nox-laptop.student.utwente.nl (nox-laptop.student.utwente.nl [130.89.160.140]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id p181S6P4025999; Tue, 8 Feb 2011 02:28:06 +0100 From: Pieter de Goeje To: "Jung-uk Kim" Date: Tue, 8 Feb 2011 02:28:05 +0100 User-Agent: KMail/1.9.10 References: <201101261721.58069.jkim@FreeBSD.org> <201102041932.43679.jkim@FreeBSD.org> <201102071807.21551.jkim@FreeBSD.org> In-Reply-To: <201102071807.21551.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201102080228.05813.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Mike Jakubik , freebsd-java@freebsd.org Subject: Re: [CFT] Update OpenJDK6 to b21 X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:28:14 -0000 On Tuesday 08 February 2011 00:07:18 Jung-uk Kim wrote: > On Friday 04 February 2011 07:32 pm, Jung-uk Kim wrote: > > On Thursday 03 February 2011 09:11 pm, Jung-uk Kim wrote: > > > On Thursday 03 February 2011 04:24 pm, Jung-uk Kim wrote: > > > > On Thursday 03 February 2011 01:09 pm, Mike Jakubik wrote: > > > > > On Wed, 2011-02-02 at 13:54 -0500, Jung-uk Kim wrote: > > > > > > Yeah, I actually fixed that. Some patches were missing in > > > > > > b20 ports. 'jstack -m' should work, too. :-) > > > > > > > > > > > > Thanks for testing! > > > > > > > > > > Compiled OK and working with my applications OK. The jstack > > > > > -m option you mention however produces the following results > > > > > here: > > > > > > > > > > Attaching to process ID 84046, please wait... > > > > > Debugger attached successfully. > > > > > Server compiler detected. > > > > > JVM version is 19.0-b09 > > > > > sun.jvm.hotspot.debugger.DebuggerException: > > > > > sun.jvm.hotspot.debugger.DebuggerException: get_thread_regs > > > > > failed for a lwp > > > > > at sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal > > > > > $BsdDebuggerLocalWorkerThread.execute(BsdDebuggerLocal.java:1 > > > > >52 ) at > > > > > sun.jvm.hotspot.debugger.bsd.BsdDebuggerLocal.getThreadIntege > > > > >rR eg is terSet(BsdDebuggerLocal.java:466) at > > > > > sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdThread.j > > > > >av a: 65 ) at > > > > > sun.jvm.hotspot.runtime.bsd_amd64.BsdAMD64JavaThreadPDAccess. > > > > >ge tC ur rentFrameGuess(BsdAMD64JavaThreadPDAccess.java:92) at > > > > > sun.jvm.hotspot.runtime.JavaThread.getCurrentFrameGuess(JavaT > > > > >hr ea d. java:256) at > > > > > sun.jvm.hotspot.runtime.JavaThread.getLastJavaVFrameDbg(JavaT > > > > >hr ea d. java:218) at > > > > > sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:208) > > > > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:66) > > > > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:53) > > > > > at sun.jvm.hotspot.tools.PStack.run(PStack.java:48) > > > > > at sun.jvm.hotspot.tools.JStack.run(JStack.java:60) > > > > > at sun.jvm.hotspot.tools.Tool.start(Tool.java:221) > > > > > at sun.jvm.hotspot.tools.JStack.main(JStack.java:86) > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > > > > Method) at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcces > > > > >so rI mp l.java:57) at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMet > > > > >ho dA cc essorImpl.java:43) at > > > > > java.lang.reflect.Method.invoke(Method.java:616) > > > > > at sun.tools.jstack.JStack.runJStackTool(JStack.java:136) > > > > > at sun.tools.jstack.JStack.main(JStack.java:102) > > > > > > > > Yeah, I noticed that, too. It seems it's getting bogus thread > > > > IDs. It'll take some time for me to figure out why, though. :-( > > > > > > Now I know why but it is a very complicated problem. :-( > > > > > > Basically, the culprit was difference between Linux and BSD, > > > mostly _thread_id and ptrace(2). Linux has gettid(2), which > > > returns a (32-bit) pid_t type, and it is used for _thread_id. > > > Linux code simply calls ptrace(PTRACE_GETREGS, ...) with it and > > > it works fine. However, BSD does not have gettid(), so we used > > > pthread_t instead. Alas, we copied process_get_lwp_regs() from > > > Linux-specific file. It does not work for us because _thread_id > > > is a pthread_t type and ptrace() does not understand it. > > > Unfortunately, there is no easy way to map pthread_t to a lwpid_t > > > value, either. More worse, it gets truncated to 32-bit on amd64. > > > Grrr... > > > > To prove my idea, I just implemented libthr function > > pthread_getthreadid_np(): > > > > http://docs.freebsd.org/cgi/mid.cgi?201102041409.12314.jkim > > > > Updated ports to support this new feature: > > > > http://people.freebsd.org/~jkim/ports-openjdk6-b21_3.tar.bz2 > > > > Since it is extremely experimental, it is turned off by default, of > > course. If you dare to try it out, you must update libthr with the > > above libthr patch and forcefully define > > HAVE_PTHREAD_GETTHREADID_NP in the ports Makefile. Now jstack can > > trace Java threads properly for me. :-) > > Please try this: > > http://people.freebsd.org/~jkim/ports-openjdk6-b21_4.tar.bz2 > > FYI, (simplified) libthr patch mentioned above was committed on HEAD. > However, when pthread_getthreadid_np(3) is not available, now it uses > (undocumented) thr_self() to get the same info. So, there is no need > to patch libthr any more. :-) Hmm, it fails to build for me: { \ echo Linking launcher...; \ \ /usr/bin/gcc -m64 -Xlinker -O1 -m64 -export-dynamic -L`pwd` -o gamma launcher.o -ljvm -lm -pthread; \ \ [ -f gamma ] || { ln -s gamma gamma; }; \ } Linking launcher... /ssd/obj/usr/home/pyotr/build/java-port/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product/libjvm.so: undefined reference to `thr_self(long*)' gmake[6]: stat: gamma: Too many levels of symbolic links gmake[6]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' All done. gmake[5]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work/build/bsd-amd64/hotspot/outputdir/bsd_amd64_compiler2/product' cd bsd_amd64_compiler2/product && ./test_gamma openjdk full version "1.6.0-b21" ./test_gamma: ./gamma: Too many levels of symbolic links gmake[4]: *** [product] Error 2 gmake[4]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work/build/bsd-amd64/hotspot/outputdir' gmake[3]: *** [generic_build2] Error 2 gmake[3]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work/hotspot/make' gmake[2]: *** [product] Error 2 gmake[2]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work/hotspot/make' gmake[1]: *** [hotspot-build] Error 2 gmake[1]: Leaving directory `/ssd/obj/usr/home/pyotr/build/java-port/work' gmake: *** [build_product_image] Error 2 *** Error code 1 Stop in /usr/home/pyotr/build/java-port. Which is weird because the symbol seems to be available in libthr and gamma is linked with -pthread: # nm -D /lib/libthr.so.3 | grep thr_self U thr_self Environment: FreeBSD xxx 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2: Mon Jan 31 23:07:50 CET 2011 xxx:/ssd/obj/ssd/FreeBSD/8.x/src/sys/GENERIC amd64 I didn't touch or patch libthr at all. Regards, Pieter de Goeje