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

[David Holmes]

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
>