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

[David Holmes]

Thanks Thomas.

I have to decide which way to go with this :)

Opinions from other runtime folk would be appreciated ... Dan? Coleen? :)

David

On 10/02/2016 6:47 PM, Thomas Stüfe wrote:
> 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
> <mailto: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
>
>
>
>
>
>