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

[Derek White]

I'll spin this part (active_processor_count() vs processor_count()) as a 
separate RFE. Earlier web searches turned up similar discussions on the 
linux kernel mailing lists on what really should be counted.

- Derek

On 4/23/15 1:13 PM, Jon Masamitsu wrote:
> On 04/23/2015 12:46 AM, Bengt Rutisson wrote:
>> On 22/04/15 17:45, Jon Masamitsu wrote:
>>> On 4/21/2015 2:57 PM, bill pittore wrote:
>>>> ...
>>>> 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().
>>>
>>> An early implementation used processor_count() and there was some 
>>> issue with virtualization.
>>> I forget what the virtualization was but it was something like 
>>> Solaris containers or zones.  Let me
>>> call them containers.  A container on an 8 processor machine might 
>>> only get 1 processor but
>>> processor_count() would return 8.   It may also have been on a 
>>> system where there were 8
>>> processors but 7 were disabled.  Only 1 processor was available to 
>>> execute the JVM but
>>> processor_count() returned 8.  Anyway, if anyone thinks it should be 
>>> processor_count()
>>> instead of active_processor_count(), check those types of situations.
>>
>> Jon,
>>
>> In the hg repo it has always been active_processor_count(). I was not 
>> able to figure out exactly when it was changed from 
>> processor_count(), but back in 2003 when JDK-4804915 was pushed it 
>> was already active_processor_count(). So, maybe it is worth 
>> re-evaluating processor_count() again. I don't pretend that I know 
>> what the correct answer here is, it just feels like a lot has 
>> happened in the virtualization area over the past 10+ years so maybe 
>> we should reconsider how we calculate the number of worker threads. 
>> Especially if it causes problems on embedded.
>
> No argument there.  I just wanted to point out situations where it
> might matter.
>
>>
>> Also, I find the comment for active_processor_count() a bit worrying.
>>
>>   // Returns the number of CPUs this process is currently allowed to 
>> run on.
>>   // Note that on some OSes this can change dynamically.
>>   static int active_processor_count();
>>
>> We read it only once and set the static value for ParallelGCThreads 
>> based on this. But apparently it can change over time so why do we 
>> think that we get a good value to start with?
>
> At the time the number of parallel GC threads could not change so
> we were stuck with the value at the start.  Even today increasing
> beyond the original maximum GC threads would take some work
> (arrays sized for the maximum number of GC threads, for example).
> There's plenty of ergonomics work like that to do.
>
> Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150423/fe9f7538/attachment.htm>