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

[Jon Masamitsu]

On 4/21/2015 1:56 PM, Derek White wrote:
> Thanks  Jon!
>
> 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)?
> This may not catch all of the failures. What I couldn't pin down was 
> why some 2, 3(!), or 4 core ARM machines would result in defaulting 
> ParallelGCThreads=1. Now these were embedded machines, with 
> potentially "odd" versions of linux, possibly with "odd" errata. Or 
> perhaps there was some dynamic differences between "installed" and 
> "on-line" cores.
>
> In any case the safest test seemed to be to force ParallelGCThreads=1 
> and see if it works.

I don't think I said it right.  What I meant was that 
testDynamicNumberOfGCThread()
should always test both cases (emulate_uniprocessor true and false) 
instead of calling
testDynamicNumberOfGCThread() twice, once with emulate_uniprocessor true 
and once
with emulate_uniprocessor false.  Was that what you responded to?

Jon


>> 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.
> OK.
>> 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.
>
> Looking into changing TEST.group...
>
> BTW, I tested with jprt earlier, but I'll try to get an Aurora run in.
>
>
>  - Derek
>>> 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/20150422/21288eff/attachment.htm>