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

[Kim Barrett]

On Nov 10, 2014, at 7:57 AM, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
> Thanks for splitting the tests up. They look fine to me now. Except that now that they are specialized I guess they could be moved into the test/gc/cms and test/gc/g1 folders.

I thought about that, but felt that keeping the two closely related tests close together was better than separating them into the respective GC folders.

> Is the  -XX:SurvivorAlignmentInBytes=2k really required for the test to fail without the patch? In that case I think it is not enough to ignore the test since I *think* Jon's idea to fix JDK-8060463 is to limit what values are allowed for SurvivorAlignmentInBytes. Jon would know more about that.

I talked to Jon, and he confirmed that limiting the permitted values
for SurvivorAlignmentInBytes to something sane was the intended
approach.  So that is indeed a problem for my regression test.  That
test was cribbed from the 8062036 reproducer.

I have not yet been able to find an alternative trigger, though
searching for one has led to some interesting spelunking. Of course,
that doesn't mean there isn't an alternative; the number of options
and their possible interactions gives a pretty large search space.

To trigger for G1 we need to somehow cause the concurrent mark thread
to perform a GC remark fairly early in VM initialization. My attempts
to create that situation have so far resulted in being too late to hit
the problematic window, or blowing up for other reasons (such as heap
size just being too small).

Much as I think tests are a good thing, I'm getting to the point of
wondering whether a regression test for this is worth the effort.