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

[Jon Masamitsu]

Derek,

Fix and test look good.

Reviewed.

Jon

On 04/28/2015 06:35 AM, Derek White wrote:
> Thanks Bengt!
>
> On 4/28/15 4:43 AM, Bengt Rutisson wrote:
>> On 28/04/15 00:14, Derek White wrote:
>>> 3rd webrev:
>>>
>>> Please review this fix for:
>>> https://bugs.openjdk.java.net/browse/JDK-8076995
>>> Webrev:
>>> http://cr.openjdk.java.net/~drwhite/8076995/webrev.02/
>>
>> The link above actually goes to webrev.01, but going to webrev.02 
>> works and that change looks good to me. Reviewed.
>>>
>>> Changes:
>>>
>>> - Updated TEST.groups to only run this test if G1, CMS, and Parallel 
>>> GCs are enabled. Removed code from webrev.01 that also updated other 
>>> GC tests. This is now tracked as a separate bug 
>>> https://bugs.openjdk.java.net/browse/JDK-8078673
>>
>> Thanks for creating this bug to track the other tests that need to be 
>> updated! Can you add a comment to JDK-8078673 that lists the tests 
>> that you have identified as problematic?
>>
>> Thanks,
>> Bengt
>>
>>>
>>> FYI also created separate bug to track the processor count issues: 
>>> https://bugs.openjdk.java.net/browse/JDK-8078703
>>>
>>> Thanks!
>>>
>>>  - Derek
>>>
>>> On 4/27/15 4:04 AM, Bengt Rutisson wrote:
>>>>
>>>> Hi Derek,
>>>>
>>>> On 2015-04-23 23:55, Derek White wrote:
>>>>> 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.
>>>>
>>>> OK.
>>>>
>>>>> - 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
>>>>>
>>>>
>>>> I think I would prefer this as a separate change. I'm not very good 
>>>> with TEST.groups, but it looks like your suggested changes are 
>>>> correct. However, I would prefer the get more attention to that 
>>>> change and thus it would be better to send it out as a separate review.
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>> - 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/20150428/f5645110/attachment.htm>