More information on mysterious garabage collection hang "introduced" in GCJ 3.3

[Øyvind Harboe <oyvind dot harboe at zylin dot com>]

I recently made a posting about my troubles with deadlock and crashes
when trying to switch to GCJ 3.3.

Some more pieces to the puzzle:

- As is indicated in my earlier posting, serial ports and 
the garbage collector is somehow involved.
http://gcc.gnu.org/ml/java/2003-03/msg00371.html

- I was using serialio.com's javax.comm. (The reason I started using
this serialio.com's, is that Suns javax.comm has Java Web Start issues).

- I switched back to Suns javax.comm. This requires a small trick I
picked up in Suns JWS forum:

			// avoid dependency on the silly
javax.comm.properties file
			// works for Java Web Start *and* GCJ.
			String driverName = "com.sun.comm.Win32Driver";
			try
			{
				javax.comm.CommDriver commDriver =
					(javax.comm.CommDriver) Class
						.forName(driverName)
						.newInstance();
				commDriver.initialize();
			} catch (ClassNotFoundException e)
			{
				e.printStackTrace();
			} catch (InstantiationException e)
			{
				e.printStackTrace();
			} catch (IllegalAccessException e)
			{
				e.printStackTrace();
			}


- I switch to compiling with GCJ 3.3


Results:

- The mysterious startup pagefault I reported earlier is gone.
My 3.2 compiled will crash once in a blue moon, even if I use
Suns javax.comm 
- The livelock/deadlock that I previously exprienced with my
GCJ 3.3 executable is gone

I believe these are two seperate problems, since the startup 
pagefault happens regardless of serialport library used.

AFAIK, this fixes all the outstanding showstoppers I had with 
GCJ 3.3 and I've cut a new release candiate of our app that is 
going through QA as I write this.

Speculation:

>From my previous debug session, I *believe* that javax.comm from
serialio.com causes a pagefault in its finalize() method(from JNI?). The

GCJ 3.2 and GCJ 3.3 garbage collector somehow treats this 
differently.



Øyvind