java.lang.Thread.start() doesn't work?

java.lang.Thread.start() doesn't work?

[Lars Andersen]

I'm running on the latest cvs-checkout on x86 linux. (one day old)

I can compile and run rather large and complex java-programs with gcj, 
but :

I can't make java.lang.Thread.start() work!

Here is an trivial example (More or less copied from the jdk1.3.1 
javadoc on java.lang.Thread :

 >>>

public class TestThread extends Thread
{
    public TestThread()
    {
    }
   
    public synchronized void start()
    {
    super.start();       
    }

    public void run()
    {
       for (int i=0; i<1000000000; i++) { if (i%10000000==0) 
System.out.print("."); }
    }
   
    public static void main(String args[])
    {
        TestThread p = new TestThread();
        new Thread(p).start();
    }
   
}

<<<

Needless to say, this code runs fine with sun jdk.

Compiled with gcj using :

gcj  TestThread.java  --main=TestThread


When running the resulting binary it produces the following output :

Exception in thread "main" java.lang.InternalError: Thread.start called 
but threads not available
   at 0x40266270: java.lang.Throwable.Throwable(java.lang.String) 
(/usr/local/lib/libgcj.so.3)
   at 0x402551f6: java.lang.Error.Error(java.lang.String) 
(/usr/local/lib/libgcj.so.3)
   at 0x40266606: 
java.lang.VirtualMachineError.VirtualMachineError(java.lang.String) 
(/usr/local/lib/libgcj.so.3)
   at 0x40257396: 
java.lang.InternalError.InternalError(java.lang.String) 
(/usr/local/lib/libgcj.so.3)
   at 0x403d4928: _Jv_ThreadStart(java.lang.Thread, int, void 
()(java.lang.Thread)) (/usr/local/lib/libgcj.so.3)
   at 0x40247f51: java.lang.Thread.start() (/usr/local/lib/libgcj.so.3)
   at 0x0804906e: ?? (/home/gb/rpm/BUILD/glibc-2.2.4/csu/init.c:0)
   at 0x4023c728: gnu.gcj.runtime.FirstThread.call_main() 
(/usr/local/lib/libgcj.so.3)
   at 0x402c5268: gnu.gcj.runtime.FirstThread.run() 
(/usr/local/lib/libgcj.so.3)
   at 0x40247ebc: _Jv_ThreadRun(java.lang.Thread) 
(/usr/local/lib/libgcj.so.3)
   at 0x40221464: _Jv_RunMain(java.lang.Class, byte const, int, byte 
const, boolean) (/usr/local/lib/libgcj.so.3)
   at 0x4022158d: JvRunMain (/usr/local/lib/libgcj.so.3)
   at 0x08048dd4: ?? (/home/gb/rpm/BUILD/glibc-2.2.4/csu/init.c:0)
   at 0x40609280: __libc_start_main (/lib/libc.so.6)
   at 0x08048cb1: _start (??:0)

Since java.lang.Thread is in libgcj, I would expect this code to work?

/Lars Andersen 

java.lang.Thread.start() doesn't work?

[Andrew Haley]

Lars Andersen writes:
 > I'm running on the latest cvs-checkout on x86 linux. (one day old)

I guess you didn't configure with --enable-threads=posix, ergo no
threads.

Andrew.

Re: java.lang.Thread.start() doesn't work?

[Anthony Green]

On Fri, 2002-04-19 at 07:20, Lars Andersen wrote:
> I can't make java.lang.Thread.start() work!

Did you configure GCC with --enable-threads?

AG

Re: java.lang.Thread.start() doesn't work?

[Lars Andersen]

Anthony Green wrote:

>On Fri, 2002-04-19 at 07:20, Lars Andersen wrote:
>  
>
>>I can't make java.lang.Thread.start() work!
>>    
>>
>
>Did you configure GCC with --enable-threads?
>
>AG
>  
>

--enable-threads==posix (suggested in previous reply does not work - produces an error during make)

--enable-threads        (works)

My big application (200+ classes) which spawns lots of threads and uses xerces for xml-parsing now appear to be working perfectly.

My first perception is a clear improvement in performance.

I will now proceed with more testing and some sort of benchmarking.

Thanks guys!


/Lars Andersen

Re: java.lang.Thread.start() doesn't work?

[Tom Tromey]

>>>>> "Lars" == Lars Andersen <lars@rimfaxe.com> writes:

Lars> --enable-threads==posix (suggested in previous reply does not
Lars> work - produces an error during make)

Use one `=', not two.

Tom

Re: java.lang.Thread.start() doesn't work?

[Anthony Green]

On Fri, 2002-04-19 at 09:16, Lars Andersen wrote:
> --enable-threads==posix (suggested in previous reply does not work - produces an error during make)

--enable-threads=posix (only one '=')

> My big application (200+ classes) which spawns lots of threads and uses xerces for xml-parsing now appear to be working perfectly.
> 
> My first perception is a clear improvement in performance.
> 
> I will now proceed with more testing and some sort of benchmarking.

Great!  Looking forward to the results...

AG