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

[Bengt Rutisson]

On 2015-04-23 19:52, Derek White wrote:
> 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.

Good idea. :)

Bengt

>
> - 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/20150424/6852541c/attachment.htm>