[8u] RFR for JDK-8154324: Request to backport JDK-6515172 to 8u

[Shafi Ahmad]

Thanks David for reviewing it. 

May I have one more thumps up.

Regards,
Shafi 

> -----Original Message-----
> From: David Holmes
> Sent: Monday, September 12, 2016 12:21 PM
> To: Shafi Ahmad
> Subject: Re: [8u] RFR for JDK-8154324: Request to backport JDK-6515172 to
> 8u
> 
> 
> 
> On 12/09/2016 4:17 PM, Shafi Ahmad wrote:
> > Hi David,
> >
> >> -----Original Message-----
> >> From: David Holmes
> >> Sent: Monday, September 12, 2016 10:52 AM
> >> To: Shafi Ahmad
> >> Subject: Re: [8u] RFR for JDK-8154324: Request to backport
> >> JDK-6515172 to 8u
> >>
> >> Hi Shafi,
> >>
> >> On 12/09/2016 2:54 PM, Shafi Ahmad wrote:
> >>> Hi David,
> >>>
> >>> Thanks for looking into it.
> >>> From the comment of Andreas in the bugdb bug
> >>
> https://bug.oraclecorp.com/pls/bug/webbug_print.show?c_rptno=23026050
> >> it appears to me he has resolved the issues but I am not sure.
> >>
> >> I'm not sure either. I don't know if this reduced form is what was
> >> need to avoid the glibc issues, or whether there may still be issues.
> >
> > From his comment
> > 	Internal notes:
> > 	We had some issues with this backport. We are building with glibc
> 2.8, while
> > 	our minimum supported system runs with glibc 2.4.
> > 	The backport will have to be adjusted, I'll upload a patch that should
> work,
> > 	but I've not tested it extensively.
> > After this comment he had attached the diff [in the bugdb] so it looks like
> diff file attached in the bugdb bug is free from libc issue.
> >
> > In the diff file I am seeing only few libc functions:
> > 1. sched_getaffinity
> > Versions : The CPU affinity system calls were introduced in Linux kernel
> 2.5.8. The system call wrappers were introduced in glibc 2.3. Initially, the glibc
> interfaces included a cpusetsize argument, typed as unsigned int. In glibc
> 2.3.3, the cpusetsize argument was removed, but was then restored in glibc
> 2.3.4, with type size_t.
> >
> > 2. CPU_ISSET
> > Versions: The CPU_ZERO(), CPU_SET(), CPU_CLR(), and CPU_ISSET()
> macros were added in glibc 2.3.3.
> > All these functions are added in glibc 2.3 and our minimum supported
> version is 2.4 so its fine.
> 
> Ok.
> 
> >>
> >>> Yes you are right there are some unused code and unrelated comment
> >>> in
> >> the attached webrev like:
> >>>  > diagnostic(bool, UseCpuAllocPath, false,  > + // If it appears
> >>> there may be more than 1024 processors then we do a I am sorry I
> >>> should verify it before sending it for review. I will remove these.
> >>>
> >>> Somehow we have missed this issue for long and customer needs the
> >>> fix in
> >> Oct release so it will be great if we can resolve it earliest.
> >>
> >> What form of the fix has the customer tested?
> > I am not aware of it whether customer has tested this fix or not. There is no
> such update in the bug.
> > But the newly added test case fails without this fix and passes with this fix.
> 
> Ok. Let's push ahead then.
> 
> Thanks,
> David
> 
> > Regards,
> > Shafi
> >
> >>
> >> David
> >>
> >>> Regards,
> >>> Shafi
> >>>
> >>>> -----Original Message-----
> >>>> From: David Holmes
> >>>> Sent: Friday, September 09, 2016 11:29 AM
> >>>> To: Shafi Ahmad; hotspot-dev at openjdk.java.net
> >>>> Subject: Re: [8u] RFR for JDK-8154324: Request to backport
> >>>> JDK-6515172 to 8u
> >>>>
> >>>> Hi Shafi,
> >>>>
> >>>> On 9/09/2016 3:46 PM, Shafi Ahmad wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Please review the backport [modified] of bug: "JDK-6515172
> >>>> Runtime.availableProcessors() ignores Linux taskset command" to
> jdk8u.
> >>>>>
> >>>>> Please note that the backport is not clean and we can't do as it is.
> >>>>> Please
> >>>> note
> >>>>>   1. The changes are made by 'Andreas Eriksson' who left Oracle.
> >>>>>   2. There is difference in logging mechanism in jdk9 and jdk8 is
> >>>>> different
> >>>> and file logTag.hpp doesn't exists in jdk8.
> >>>>>   3. Newly added test pass after this change. It fails without this
> change.
> >>>>>
> >>>>> Webrev link:
> >> http://cr.openjdk.java.net/~shshahma/8154324/webrev.00/
> >>>>> Jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6515172
> >>>>> Jdk8 bug: https://bugs.openjdk.java.net/browse/JDK-8154324
> >>>>> Original patch pushed to jdk9:
> >>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/c5480d4abfe4
> >>>>
> >>>> I worked extensively with Andreas on this as there were a number of
> >> issues.
> >>>> I'll have to try and find those discussions to see where we ended up.
> >>>>
> >>>> The backport as stands is not quite appropriate. For example it adds:
> >>>>
> >>>> diagnostic(bool, UseCpuAllocPath, false,
> >>>>
> >>>> but that does not exist in the actual code for 8.
> >>>>
> >>>> Also this comment:
> >>>>
> >>>> + // If it appears there may be more than 1024 processors then we
> >>>> + do a // dynamic check - see 6515172 for details.
> >>>>
> >>>> is wrong as there is no dynamic check in this version of the code.
> >>>>
> >>>> The last I recall with this is that there were issues caused by
> >>>> building with one version of glibc and running (or trying to) on
> >>>> later versions of glibc. But as I said I will have to see if I have
> >>>> the discussion
> >> from that effort.
> >>>>
> >>>> David
> >>>> ----
> >>>>
> >>>>> Testing: jprt and running jtreg.
> >>>>>
> >>>>> Regards,
> >>>>> Shafi
> >>>>>