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

[Bengt Rutisson]

Hi Kim,

On 2014-11-10 07:09, Kim Barrett wrote:
> On Nov 7, 2014, at 5:47 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>> On Nov 7, 2014, at 12:33 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
>>>> Anyway, I think it would be good to explicitly add the GC to the @run command. Otherwise these tests will be run in many places, nightly testing for the other groups, PIT testing, manual testing, ad hoc aurora runs, et.c. without actually testing anything.
>>>>
>>>> Since the test is so simple I think splitting it up into two files is the simplest workaround for the @requires limitation for now.
>>> Thinking about this more overnight, I was approaching the same conclusion; so that’s what I’ll do.
>> New webrev with test split for G1 and CMS:
>>
>> http://cr.openjdk.java.net/~kbarrett/8062036/webrev03
>>
>> Note that the CMS test intermittently fails even with these changes, due
>> to https://bugs.openjdk.java.net/browse/JDK-8060467.
>>
>> I'll either need to wait for John Coombs to push his fix for that one
>> (it's already been reviewed), or add a temporary @ignore line to my
>> CMS test.
> It turns out the reference to JDK-8060467 from JDK-8062036 was to the wrong bug; it should have been JDK-8060463.  So John’s fix for the former doesn’t address the misbehavior of the new test being added for JDK-8062036.  I didn’t notice this previously because I didn’t carefully check the failure with CMS that I was seeing against the referenced bug until it still failed in the same way after incorporating John’s fix into my forest.  So I’ll be adding “@ignore 8060463” to the CMS test in the above webrev.

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.

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.


Bengt


>
>