Date: Tue, 8 Feb 2011 12:05:04 -0500 From: Jung-uk Kim <jkim@FreeBSD.org> To: freebsd-java@freebsd.org Cc: Pieter de Goeje <pieter@degoeje.nl> Subject: Re: [CFT] Update OpenJDK6 to b21 Message-ID: <201102081205.17237.jkim@FreeBSD.org> In-Reply-To: <20110208054115.GA15525@misty.eyesbeyond.com> References: <201101261721.58069.jkim@FreeBSD.org> <201102080228.05813.pieter@degoeje.nl> <20110208054115.GA15525@misty.eyesbeyond.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 08 February 2011 12:41 am, Greg Lewis wrote: > On Tue, Feb 08, 2011 at 02:28:05AM +0100, Pieter de Goeje wrote: > > 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.getThread > > > > > > >Intege rR eg is terSet(BsdDebuggerLocal.java:466) at > > > > > > > sun.jvm.hotspot.debugger.bsd.BsdThread.getContext(BsdTh > > > > > > >read.j av a: 65 ) at > > > > > > > sun.jvm.hotspot.runtime.bsd_amd64.BsdAMD64JavaThreadPDA > > > > > > >ccess. 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.jav > > > > > > >a: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(NativeMetho > > > > > > >dAcces so rI mp l.java:57) at > > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegat > > > > > > >ingMet 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/hots > >pot/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/hot > >spot/outputdir/bsd_amd64_compiler2/product' All done. > > gmake[5]: Leaving directory > > `/ssd/obj/usr/home/pyotr/build/java-port/work/build/bsd-amd64/hot > >spot/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/hot > >spot/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. > > Same result for me on FreeBSD/i386 8.1. > > > 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. > > Not a problem due to libthr IMO. I found the culprit: http://svn.freebsd.org/viewvc/base?view=revision&revision=206903 It was never MFC'ed. I guess it worked for me because I am using CURRENT. What's the best way to solve this C++ namespace problem *without* explicit extern "C" (i.e., some versions have this already)? Will ::thr_self() just work? :-( Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102081205.17237.jkim>