Tom and Bryce made a patch to fix the class loader deadlock that Bryce
said was blocking testsuite runs, and I applied it.
I thought it might be interesting to run the testsuite, but I
remembered Bryce's comment about running out of memory with many
threads, so I reduced the thread stack size to 256k, which is the same
as Sun IIRC.
I ran the testsuite, and got some results: 91.07% success rate.
Running the same tests with IBM's jvm gets 95.75%. This is good, I
The *really* good news is that JOnAS did not grow unreasonably: it
never exceeded about 300M. On that basis, I don't think there's any
pressing need to search for memory leaks.
However, the test harness was running under IBM's java, not gcj.
That's why the test result is reported as IBM. JOnAS itself was
running on gcj. I had trouble running the test harness itself on gcj,
so I'm going to explore that later if I get the chance. It seems that
the test harness relies on some correct behaviour of javax.naming that
we're not handling correctly: all the tests fail on the harness side
with traces like
Exception raised in setup: javax.naming.NamingException: javax.naming.NamingException:
name "bankManagerROHome" not bound Caused by:
javax.naming.NameNotFoundException: name "bankManagerROHome" not bound at
So, we need to find out why all tests fail with a
javax.naming.NameNotFoundException when the test harness is run under
gcj. Many of the test failures also seem to be caused by a
javax.naming.NameNotFoundException, so this might be a common problem.
On the downside:
I saw the deadlock in the class loader again, even after Bryce's
patch. I'll try to liase with Tom and Bryce to do some more
gcj is not correctly initializing JOnAS' trace properties. This
means that it's impossible to enable -- for example -- CAROL
tracing. This is v.v.v. annoying, so I'm going to investigate it.