Date: Mon, 3 Dec 2007 08:18:32 -0700 From: Nate Williams <nate@yogotech.com> To: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr> Cc: Daniel Eischen <deischen@freebsd.org>, java@freebsd.org, nate@yogotech.com, julian@freebsd.org, David Xu <davidxu@freebsd.org> Subject: Re: cvs commit: src/lib/libkse/thread thr_kern.c Message-ID: <18260.7752.293904.909660@caddis.yogotech.com> In-Reply-To: <wp4pezc1zl.fsf@heho.snv.jussieu.fr> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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). 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. Java's threading model allows one to write bug-free code as the model is very simple, but you have to be *very* careful with it and when you do, performance can suffer so many times developers take short-cuts as it doesn't appear to negatively effect their code during development on their platform of choice. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18260.7752.293904.909660>