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

[bill pittore]

On 4/21/2015 4: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.
There is definitely a difference between the processor count and the 
online processor count.  It seems that the calculation of 
ParallelGCThreads uses the online count which could easily be 1 on some 
embedded platform since the kernel does do active power management by 
shutting off cores.  The comment in os.hpp for active_processor_count() 
says "Returns the number of CPUs this process is currently allowed to 
run on".  On linux at least I don't think that's correct. Cores could be 
powered down just because the kernel is in some low power state and not 
because of some affinity property for this particular Java process. I'd 
change the calculation to call processor_count() instead of 
active_processor_count().

bill

>
> In any case the safest test seemed to be to force ParallelGCThreads=1 
> and see if it works.
>> 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/20150421/944f205d/attachment.htm>