cvs commit: src/lib/libkse/thread thr_kern.c

[Arno J. Klaassen]

Hello,

Nate Williams <nate at 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