JDK-4336548 : [solaris i386] Compiler Safepoints do not work on multiprocessor systems
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2000-05-08
  • Updated: 2012-10-08
  • Resolved: 2000-07-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 sol-beta2Fixed
Related Reports
Relates :  
Relates :  
Description
This is a copy of 4317961 which was for SPARC (which is now fixed.)

Problem occurs when thr_getstate returns a flag value of TRS_NONVOLATILE
in fetch_top_frame_fast.  The i386 code for fetch_top_frame_fast returns
a null pc/sp, restarts the thread, and tries to suppend again.  Unfortunately,
the thread with the infinite loop is always in a state in which TRS_NONVOLATILE
is returned, so GC never runs.

Compiler safepoints do not work.

Run the appended program with following commandline
and it will hang with both compilers
java -Xcomp -verbose:gc sf

Run it with following commandline and it terminates properly:
java -Xint -verbose:gc sf

The program hangs if the method loop is compiled because
the runtime cannot properly suspend the endless loop.
I have verified that both Compiler 1 and Compiler 2 (server) are
emitting safepoint information.



----------------
public class sf {
        static public boolean _xx = true;

	public static void main(String[] args) {
		new Srdjan().start();
	}
	
	public void start() {
		new TesterThread().start();
		new GCThread().start();	
	}
	
	class TesterThread extends Thread {

                // trick compiler 2 in believing that this is not and endless loop
                public void loop (int n) {
			long counter = 0;
			while (_xx) {
				if (n == 0) {
                                  _xx = false;
                                }
			}
                }
		public void run () {
			System.out.println("Start loop");
                        loop(3);
		}
	}

	class GCThread extends Thread {
		public void run () {
			System.out.println("Starting GC loop");
			long counter = 0;
			while (true) {
			  try { sleep(250); } catch (InterruptedException ix) {}
				System.gc();
                                counter++;
                                if (counter == 10) {
                                  _xx = false;
                                  return;
                                }
			}
		}
	}
}

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kest-sol-beta2 FIXED IN: kest-sol-beta2 INTEGRATED IN: kest-sol-beta2
14-06-2004

EVALUATION This problem was caused by disabling get_ucontext_from_siglwp_handler which prevented us from being able to get the pc of a thread looping in compiled code so that we could patch it and get it to a safepoint. This code was disabled because it was subject to possible seg. faults as it traversed the stack. The code has been made robust and should not segv. and has been reenabled. steve.goldman@east 2000-06-22
22-06-2000