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

[Andreas Eriksson]

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.

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