[CFT] Update OpenJDK6 to b21

Jung-uk Kim jkim at FreeBSD.org
Tue Feb 8 17:05:25 UTC 2011


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


More information about the freebsd-java mailing list