RFR (S): 8076995: gc/ergonomics/TestDynamicNumberOfGCThreads.java failed with java.lang.RuntimeException: 'new_active_workers' missing from stdout/stderr
bill.pittore at oracle.com
Tue Apr 21 21:57:18 UTC 2015
On 4/21/2015 4:56 PM, Derek White wrote:
> Thanks Jon!
> On 4/21/15 1:23 PM, Jon Masamitsu wrote:
>> 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
>> 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
> 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.
>> On 04/21/2015 06:53 AM, Derek White wrote:
>>> Hi All,
>>> Please review this fix for:
>>> 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.
>>> - Derek
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev