RFR: 8148987: [Linux] Allow building on older systems without CPU_ALLOC support

[Thomas Stüfe]

Hi David,

sorry for dropping the ball on this. I tested the change and it fixes the
build error on SLES10. Change looks good to me, I may have done this
differently but there are many ways to fix this.

Thank you for fixing this!

Kind Regards, Thomas

On Wed, Feb 10, 2016 at 5:48 AM, David Holmes <david.holmes at oracle.com>
wrote:

> Hi Dmitry,
>
> On 5/02/2016 11:21 PM, Dmitry Samersoff wrote:
>
>> David,
>>
>> Sorry! Wasn't clean enough.
>>
>> 1. I'm not sure we should handle all possible variants of old systems.
>>
>> i.e. it might be better to create one function for the case "everything
>> present" and one other, minimal, variant for the case where we don't
>> have any of required macro (either CPU_COUNT or CPU_ALLOC or both).
>>
>
> I'm waiting for additional feedback from others. :) Given I'm reluctant to
> even make this change in 9, I'm even more reluctant to add further
> duplication.
>
> My main motivation to change this in 9 is to take the same basic code to 8
> so that unofficial builds on later compilers can utilize the more modern
> functionality if it is available. How to handle the lack of Unified Logging
> is still TBD.
>
>
> 2. It requires some brain efforts to catch that CPU_COUNT_S at 4851 will
>> never be called if we don't have CPU_ALLOC.
>>
>
> Yeah I tried to make this clearer by redefining the _S versions with a
> ShouldNotReachHere() - but that is itself a macro and I couldn't get it to
> work - especially when I need to appear to "return" a number.
>
> Thanks,
> David
>
>
>    I would prefer to avoid implicit dependencies like this one, ever at
>> the cost of some code duplication.
>>
>> -Dmitry
>>
>> On 2016-02-05 15:21, David Holmes wrote:
>>
>>> Hi Dmitry,
>>>
>>> Thanks for looking at this.
>>>
>>> On 5/02/2016 8:46 PM, Dmitry Samersoff wrote:
>>>
>>>> David,
>>>>
>>>> I suspect that if the os don't have CPU_COUNT it doesn't have
>>>> CPU_COUNT_S as well at 4851
>>>>
>>>
>>> It is true that if you don't have CPU_COUNT you won't have the *_S
>>> macros either but I'm handling the two separately as you can have
>>> CPU_COUNT but not CPU_ALLOC. The *_S variants were added for the dynamic
>>> cpu set management, so it is determined by the existence of CPU_ALLOC.
>>>
>>> Is it possible to create two different version of
>>>> os::active_processor_count() - simple one for old systems and more
>>>> complicated one for modern linux and move define to a function level?
>>>>
>>>
>>> There are really three variants:
>>> - no CPU_COUNT or CPU_ALLOC (and *_S)
>>> - no CPU_ALLOC (and *_S)
>>> - everything present
>>>
>>> There are numerous different ways in which to represent that. I started
>>> with the has-everything version and tried to minimize the ifdefs within
>>> that code by isolating the CPU_ALLOC part. Then the CPU_COUNT part is
>>> handled separately.
>>>
>>
>>
>>
>>
>>> Thanks,
>>> David
>>>
>>> -Dmitry
>>>>
>>>> On 2016-02-05 10:50, David Holmes wrote:
>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8148987
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8148987/webrev/
>>>>>
>>>>> This is a tentative RFR as I'm not yet convinced we should support
>>>>> building on these older platforms in JDK 9. Opinions welcome on that
>>>>> point.
>>>>>
>>>>> The older systems do not have dynamic cpu set support (CPU_ALLOC) nor
>>>>> do
>>>>> they have the CPU_COUNT utility macro.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>
>>>>
>>>>
>>
>>