RFR (S): 8076995: gc/ergonomics/TestDynamicNumberOfGCThreads.java failed with java.lang.RuntimeException: 'new_active_workers' missing from stdout/stderr
derek.white at oracle.com
Tue Apr 21 20:56:33 UTC 2015
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.
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.
>> 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