8u backport RFR: 6515172 and 8148987 (Linux availableProcessors fixes)

[Andreas Eriksson]

Hi David,


On 2016-05-13 01:55, David Holmes wrote:
> On 13/05/2016 12:07 AM, Andreas Eriksson wrote:
>> Hi,
>>
>> Looks like maybe our official JDK 8 linux build platforms are using a
>> newer glibc (glibc 2.7) than our minimum supported run platform uses
>> (glibc 2.4).
>> If that is the case backporting these fixes will not work, since the
>> official builds will then use glibc 2.7 functionality and then cannot
>> run on systems with older glibc versions.
>
> What is it that is present on the build system that is not present at 
> runtime? I was not expecting any of the new stuff to be present at 
> build time (for our official builds), so only sched_getaffinity should 
> be needed. If the newer stuff is available then yes that would be a 
> problem. :(

If glibc 2.7 (or newer) is used when building, then CPU_COUNT (glibc 
2.6), CPU_ALLOC (glibc 2.7) and CPU_FREE (glibc 2.7) are used.
These macros resolve to uses of __sched_cpucount at GLIBC_2.6, 
__sched_cpualloc at GLIBC_2.7 and __sched_cpufree at GLIBC_2.7 respectively.

- Andreas

>
> David
>
>> I'm working on getting confirmation on what glibc our build platforms
>> are using.
>>
>> - Andreas
>>
>>
>> On 2016-05-05 02:37, David Holmes wrote:
>>> On 4/05/2016 9:20 PM, Andreas Eriksson wrote:
>>>> Hi David,
>>>>
>>>>
>>>> On 2016-05-04 03:55, David Holmes wrote:
>>>>> Hi Andreas,
>>>>>
>>>>> On 3/05/2016 11:18 PM, Andreas Eriksson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the backport of these two fixes:
>>>>>> 6515172: Runtime.availableProcessors() ignores Linux taskset command
>>>>>> 8148987: [Linux] Allow building on older systems without CPU_ALLOC
>>>>>> support
>>>>>>
>>>>>> Bugs:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-6515172
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148987
>>>>>>
>>>>>> Webrevs:
>>>>>> http://cr.openjdk.java.net/~aeriksso/6515172/webrev.00/
>>>>>> http://cr.openjdk.java.net/~aeriksso/8148987/webrev.00/
>>>>>
>>>>> I assume you will actually commit this a single changeset (under a
>>>>> separate CR) not as two changesets - one for each backport? The 
>>>>> change
>>>>> for 6515172 won't compile on 8u so that changeset should never exist
>>>>> as it stands in 8u. I would want to see a single changeset and a
>>>>> corresponding webrev showing the final code against the existing 
>>>>> code.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>>>> I was planning on pushing both at the same time, as their two original
>>>> CR:s. This is to allow easier tracking of what has been backported for
>>>> us in sustaining. That 6515172 won't compile on its own doesn't 
>>>> matter,
>>>> since it will never exist in the repo without 8148987.
>>>
>>> I think you can have multiple bug fixes per changeset, so as long as
>>> the complete set of changes comprises a singe changeset I'm fine with
>>> that. Otherwise someone could easily create a repo where only the
>>> first change exists (imagine someone trying to find when a bug was
>>> introduced and applies one changeset at a time). If this is an issue
>>> then it might be better to avoid distinct backports and instead create
>>> a new bug that represents adding in the final form of this 
>>> functionality.
>>>
>>>> I uploaded a combined webrev, but I'll still push them as separate 
>>>> CR:s.
>>>> http://cr.openjdk.java.net/~aeriksso/6515172_8148987/webrev.00/
>>>
>>> Changes look fine. Have you verified (via the tracing) that all code
>>> paths work as expected?
>>>
>>> Thanks,
>>> David
>>>
>>>> Regards,
>>>> Andreas
>>>>
>>>>>
>>>>>> Changes to jdk9:
>>>>>> No unified logging, so a new Linux-only diagnostic flag,
>>>>>> PrintActiveCpus, added instead.
>>>>>> A few changes to the test were needed because of testlibrary
>>>>>> differences.
>>>>>>
>>>>>> Thanks,
>>>>>> Andreas
>>>>
>>