Date: 03 Dec 2007 21:17:07 +0100 From: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr> To: nate@yogotech.com (Nate Williams) Cc: java@freebsd.org Subject: Re: cvs commit: src/lib/libkse/thread thr_kern.c Message-ID: <wpwsrvr0sc.fsf@heho.snv.jussieu.fr> In-Reply-To: <18260.7752.293904.909660@caddis.yogotech.com> References: <200711301716.lAUHGEV1064334@repoman.freebsd.org> <wpprxrto0s.fsf@heho.snv.jussieu.fr> <Pine.GSO.4.64.0711301659060.5465@sea.ntplx.net> <wpwsrz9uyr.fsf@heho.snv.jussieu.fr> <Pine.GSO.4.64.0711301849310.6581@sea.ntplx.net> <47536361.8090203@freebsd.org> <Pine.GSO.4.64.0712022341210.17493@sea.ntplx.net> <wp4pezc1zl.fsf@heho.snv.jussieu.fr> <18260.7752.293904.909660@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Nate Williams <nate@yogotech.com> writes: > [ Java hang ] > > But the only easy way for me to reproduce it is just compiling jacorb > > (www.jacorb.org) on releng_6 (about ten days old) using libthr : after > > a while java hangs (can only be killed by -9) and 'top -H' shows three > > threads each taking 70-90% CPU-time. > > > > If I take a 'gcore' snapshot of it (dunno how trustful that is) > > it shows all threads in _thr_umtx_wait() (script-log attached). > > > > But : > > > > - only 2x2 smp-amd64 releng_6, 1x2 smp goes OK > > - only easy to produce when using optimized VM (I'll retry > > harder to produce a hang with java_g) > > - no prob on releng_7 (2x2 smp included) for this test > > > > This is thin, but all I have for now ... > > Obviously this isn't necessarily the case, but more times than not hangs > in the VM on multiple CPUs are almost always related to bugs in the Java > code. Rarely do developers write code that is multi-thread safe, and > just because code works fine on one platform doesn't mean that the code > is truly multi-thread safe. > > We had code that was originally developed under FreeBSD, but used code > from multiple vendors. We found problems in the code that were > triggered by our usage that needed to get fixed. > > Then, we we migrated the code to Windows, we found more bugs (both in > our code and other code). Finally, we found another set of bugs when we > ran the code under Solaris, and yet another class of bugs when we > switched thread models under Solaris (Solaris use to give you the option > of using different threading models for Java). Sure, I completely agree. That's why I ask my co-workers to produce me some simple test-code I can test under FreeBSD (the only platform we use in production) and test it as well under Linux/Windows and sometimes MacosX/Solaris (only maintained boxes available). > That may not be the case here, but just because something is in ports > doesn't necessarily mean it is bug free. It's certainly possible that > FreeBSD's SMP libraries may now expose incorrect assumptions the author > of the Java code never considered which will cause deadlocks using a > different threading model. Bon, I'm probably too old to write proper Java code, and old enough to understand the test code, the might be underlying OS-problems and accept the shame when the testing code was bluntly wrong. That said, I try to not too often spoil fbsd-developers with wrong PRs; but on the present matter my feeling that something is wrong with XxY-smp wrt forking has proven to be stronger than my retention to write possibly garbish. I might be wrong. I do have problems which [work|fail] on releng[6|7] using lib[thr|kse] (and never the same combination ...) The Test_cmd.java my coworkers produced me, does consistently fail on stock releng_7/libkse. The hang on releng_6 with libthr is with plain stock 'javac' *and** my 'own'(tm) java-progs exhibit the same behaviour. I doubt no-one else ever tried to javac code on XxY-smp on something else than FreeBSD. Once again, I might be wrong .. Best, Arno
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wpwsrvr0sc.fsf>