JDK1.2.2.12 concurrent GC algorithm (incmarksweep) bug?

Question

Hi all,
I have a jdk run time bug. Could you please help me?
We are currently using Sun JDK 1.2.2.12 native threads. The operating system is Sun Solaris 2.8. Hardware is Sun Netra model 1405 with four processors (sparcv9 processor operates at 440 MHz with sparcv9 floating point processor) and 2G memory. We are using some concurrent GC options as following:
/usr/jdk1.2.2_12/bin/sparc/native_threads/java -Xgenconfig:4m,4m,semispaces:256m,1200m,incmarksweep
We had several core dumps with above configuration during long time performance tests last week. The frequency is about twice a week. The output on console is as following:
SIGSEGV 11 segmentation violation
si_signo [11]: SEGV
si_errno [0]:
si_code [1]: SEGV_MAPERR [addr: 0x4]
stackpointer=FECC14B0
We did some simulations and duplicated the core dumps. We figured out that core dumps are somehow associated with concurrent GC algorithm "incmarksweep". The core dump will disappear if we replace "incmarksweep" with "markcompact". There is no problem at all if we do not use concurrency GC options. The request malloc size has significant effect on the core dump frequency. The smaller the request malloc size, the less frequent the core dump occurs. The core dump will happen immediately if we use that option with large memory allocation request size. Just put included jar file in your class path and type,
usr/jdk1.2.2_12/bin/sparc/native_threads/java -Xgenconfig:4m,4m,semispaces:600m,800m,incmarksweep test 100 1000000
where,
100 are the number threads you want to use in JVM and
1000000 are the number bytes you want JVM to allocate it for you at one time.
You will see a core dump within couple of minutes. The output on console is listed as following:
IGSEGV 11 segmentation violation
si_signo [11]: SEGV
si_errno [0]:
si_code [1]: SEGV_MAPERR [addr: 0x4]
stackpointer=FDFB11B8
*** Garbage Collection in process, a thread
*** dump is not possible.
Abort (core dumped)
import java.io.*;
import java.util.*;
public class coredump extends Thread
    long timewait;
    int  mallocSize;
    public coredump(long time, int mallocSize)
        timewait=time;
        this.mallocSize=mallocSize;
    public void run()
        byte[] test;
        int  counter = 0;
        while(true)
            test = new byte[mallocSize];
            for(int j=0;j<mallocSize;j++)
                test[j]=(byte)(j%256);
            counter++;
            System.out.println("Total allocated memory by thread " +Thread.currentThread().getName()+":"+counter*mallocSize+" bytes");
//====================================================================================================================
public class test
    public static coredump[] threads;
    public static int numThreads;
    public static int mallocSize;
    public test()
    public static void main(String[] args)
        if(args.length != 2)
            System.out.println("Usage: java -Xconfig: 4m,4m,semispaces:600m,800m,incmarksweep test numThreads mallocSize");
            System.exit(1);
        else
            numThreads=Integer.parseInt(args[0]);
            mallocSize=Integer.parseInt(args[1]);
            threads = new coredump[numThreads];
        try
            for(int i=0;i<numThreads;i++)
                threads=new coredump(1000,mallocSize);
threads[i].start();
catch(Exception ee)
ee.printStackTrace();

Answer 1

Yes. Sun reproduced and confirmed the bug in JDK 1.2.2_12 and JDK 1.2.2_13(scheduled release on 7/31/02). They are working on fix...
Thanks
xin