RFR (S): 8076995: gc/ergonomics/TestDynamicNumberOfGCThreads.java failed with java.lang.RuntimeException: 'new_active_workers' missing from stdout/stderr

[Derek White]

2nd webrev:

Please review this fix for:
https://bugs.openjdk.java.net/browse/JDK-8076995

Webrev:
http://cr.openjdk.java.net/~drwhite/8076995/webrev.01/


Changes:

- Updated TEST.groups to only run this test if G1, CMS, and Parallel GCs 
are enabled.
- Also searched for similar GC tests that specify a GC to use and added 
to TESTS.groups:

  * gc/TestSmallHeap.java
  * gc/logging/TestGCId.java
  * gc/TestCardTablePageCommits.java
  * gc/arguments/TestParallelHeapSizeFlags.java

- Responded to comments below.

Did jprt run. Saw timeout, not sure if real or if it's one of those 
"embedded tests don't quite fit" errors.
    Fail/kill comment:  Targets failed.  Target 
linux_armvfpsflt_2.6-productEmb-c2-hotspot_servertest timedout.

  - Derek

On 4/21/15 1:23 PM, Jon Masamitsu wrote:
> Derek,
>
> Thanks for fixing this.
>
> Fix looks good.
>
> What do you think about always making testDynamicNumberOfGCThread()
> check for the uniprocessor case (as opposed to passing in a flag to 
> explicitly
> check it)?
>
> ForceDynamicNumberOfGCThreads is a diagnostic flag
>
>   diagnostic(bool, ForceDynamicNumberOfGCThreads, 
> false,                    \
>           "Force dynamic selection of the number of 
> "                       \
>           "parallel threads parallel gc will use to aid 
> debugging")         \
>
> so I think you need +UnlockDiagnosticVMOptions.
>
> Jon
>
> On 04/21/2015 06:53 AM, Derek White wrote:
>> Hi All,
>>
>> Please review this fix for:
>> https://bugs.openjdk.java.net/browse/JDK-8076995
>> Webrev:
>> http://cr.openjdk.java.net/~drwhite/8076995/webrev.00/
>>
>> Summary:
>>
>> Part 1 is a test bug that tries to run G1 on embedded SE builds. Not changed by this webrev.
>>
>> Part two is assertion failure that is being fixed by this webrev.
>>
>> This is a fix for bug that triggered an assert when running CMS on very
>> small machines - 1 core x86, or 1-4 core ARM. This may seem unlikely but
>>   can easily happen when running virtual instances.
>>
>> Failure stack traces also show bug crashing printing a stack trace, but this is being tracked in another bug.
>>
>> Thanks,
>>
>> - Derek
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150423/c1670e81/attachment.htm>