Concurrently memory allocation and JNI CS provoke OOM

Despite fix for 6186200 was delivered we have still some problems in memory allocation concurently with native threads entering JNI critical sections. Later improvements in GC locker as reflected with Mustang jplan-283 feature give us hope on increasing concurrency of JNI CS and java threads.

I have created two test to cover this (in attachment).

note: gcl001 is stress test so you may need additional tuning to reproduce its failures. -Xmx64M almost required.

My runs provide following results (Mustang b37):
1) linux-suse9.2-i586
  1.1) -XX:+UseSerialGC (default for client)
gcl001 - FAIL, b6186200 - PASS
  1.2) -XX:+UseParallelGC
gcl001 - PASS, b6186200 - FAIL
  1.3) -XX:+UseConcMarkAndSweepGC
gcl001 - FAIL, b6186200 - PASS

2) Solaris-sparc 10
  1.1) -XX:+UseSerialGC (default for client)
gcl001 - FAIL, b6186200 - PASS
  1.2) -XX:+UseParallelGC
gcl001 - PASS, b6186200 - PASS
  1.3) -XX:+UseConcMarkAndSweepGC
gcl001 - PASS(slow), b6186200 - PASS


PS More intresting fact is that b6186200 never fails on solaris even with very old builds. So it worked fine ever before 6186200 integration. Linux version produce failure as expected.

PPS Full test names (for UTB script):
nsk/stress/jni/gclocker/gcl001
nsk/regression/b6186200
###@###.### 2005-06-03 14:27:25 GMT

This parameters may provide better results with gcl001:

    static private int numJNIWorker = 100;
    static private int numJNIArraySize = 50000;

    static private int numGarbageProducer = 100;
    static private int numGarbageBlockSize = 100000;
    static private int numGarbageProducerSleep = 5; // unused!

    static public int numCS = 2000;


###@###.### 2005-06-06 09:14:47 GMT
###@###.### 2005-06-23 19:00:33 GMT