JOnAS on gcj conformance test results

[Andrew Haley]

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.
Results here:
http://people.redhat.com/~aph/jeremie-Linux-HSQL1-1.4.2-$%7bwebcontainer.nam...

Running the same tests with IBM's jvm gets 95.75%.  This is good, I
think.

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: javax.naming.NameNotFoundException:   1.412
       name "bankManagerROHome" not bound Caused by: javax.naming.NameNotFoundException: name "bankManagerROHome" not bound at
       org.objectweb.jeremie.services.registry.jndi.JRMIRegistryContext.lookup(javax.naming.Name)
       (/usr/lib/libjonathan-jeremie-4.2.jar.so) at javax.naming.InitialContext.lookup(javax.naming.Name)
       (/home/aph/gcc-4_0-branch/install/lib/libgcj.so.6.0.0) at
       org.objectweb.carol.jndi.spi.JEREMIEContext.lookup(javax.naming.Name) (/usr/lib/libow_carol-1.8.9.3.jar.so) at
       org.objectweb.carol.jndi.spi.JEREMIEContext.lookup(java.lang.String) (/usr/lib/libow_carol-1.8.9.3.jar.so) at
       javax.naming.InitialContext.lookup(java.lang.String) (/home/aph/gcc-4_0-branch/install/lib/libgcj.so.6.0.0) at
       org.objectweb.carol.jndi.spi.MultiContext.lookup(java.lang.String) (/usr/lib/libow_carol-1.8.9.3.jar.so) at
       org.objectweb.carol.jndi.spi.ContextWrapper.lookup(java.lang.String) (/usr/lib/libow_carol-1.8.9.3.jar.so) at
       javax.naming.InitialContext.lookup(java.lang.String) (/home/aph/gcc-4_0-branch/install/lib/libgcj.so.6.0.0) 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
   debugging.

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.

More later.

Andrew.

[Gary Benson]

Andrew Haley wrote:
> I ran the testsuite, and got some results: 91.07% success rate.

That's pretty damn cool! :)
> On the downside:
>    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.

The logging in general seems really flaky.  Sometimes it prints
timestamps, sometimes numbers, and most times it prints the name of
the logger function rather than the function that called it.  It's one
of the things I want to look into as well.

Cheers,
Gary

[Andrew Haley]

Gary Benson writes:
> Andrew Haley wrote:
> > I ran the testsuite, and got some results: 91.07% success rate.
>
> That's pretty damn cool! :)
> > On the downside:
> >    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.
>
> The logging in general seems really flaky.  Sometimes it prints
> timestamps, sometimes numbers, and most times it prints the name of
> the logger function rather than the function that called it.  It's one
> of the things I want to look into as well.

Well, I found it.  :-)

You'll see the discussion later...

Andrew.