Skip site navigation (1)Skip section navigation (2)
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>