RFR: 8062036: ConcurrentMarkThread::slt may be invoked before ConcurrentMarkThread::makeSurrogateLockerThread causing intermittent crashes

[Kim Barrett]

On Nov 6, 2014, at 4:01 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> What does the test verify? When I run the test on a build that does
> not have your fix it still passes:
> 
> $ java -showversion -jar /localhome/tests/jtreg/lib/jtreg.jar -noreport test/gc/TestScavengeALot.java
> java version "1.9.0-ea"
> Java(TM) SE Runtime Environment (build 1.9.0-ea-b35)
> Java HotSpot(TM) 64-Bit Server VM (build 1.9.0-ea-b35, mixed mode)
> 
> Test results: passed: 1
> 
> Also, since this is a CMS specific test I think it should be located
> in the "test/gc/concurrentMarkSweep".

Without the proposed changes, the test program segfaults during VM
initialization when using a *non-product* build and using *either* G1
or CMS as the collector (plus the other options specified in the
test's @run line), e.g. the main() for the test program is never
reached with those configurations.

I may be confused about how to go about testing in this situation, but
the jtreg invocation above isn't one of the failing configurations
(it appears to be a product build, and the default GC is being used,
which isn't either G1 or CMS.)

My understanding is that at least some of our test infrastructure runs
each test with each of several GC configurations.  That doesn't appear
to be true for jtreg run directly though; to test different GC
configurations I think one needs to use -javaoptions in the jtreg
invocation.

By leaving the GC unspecified in the @run line, I'm allowing the
external invocation to choose which GC to use.  It seems at least
harmless to run the test for non-concurrent collectors (and has the
benefit of some minimal testing of the -XX:+ScavengeALot feature with
those collectors too), and we'd like the test to be run for any
concurrent collector externally specified.

I could instead explicitly specify the collector to use, by providing
two @run lines, one for G1 and one for CMS.  But then I should add a
@requires line, and I don't know how to write that @requires line in
the face of multiple @run lines with different requirements.  (This
seems like a deficiency in the new @requires mechanism.)  I think if I
were going to explicitly specify the collector, I'd need two copies of
the test, each with one @run line for the desired collector, with a
corresponding @requires line. (Script-based test trampolines to a
common .java test implementation would be an alternative if the .java
code was less trivial.)

There's no reason to run the test against a product build, and in fact
the test would fail in such a configuration were it not for the use of
-XX:+IgnoreUnrecognizedVMOptions (yuck!).  There doesn't seem to be a
better way at present to deal with that case; but see
https://bugs.openjdk.java.net/browse/CODETOOLS-7901086

Anyway, that's how I arrived at the proposed test program.  I'm happy
to fix it if there's some mistake in how I got there.