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

[David Holmes]

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. :(

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
>>>
>