[8u] RFR: Backport 8161993 G1 crashes if active_processor_count changes during startup

[Thomas Schatzl]

Hi David,

On Tue, 2016-12-20 at 06:41 +1000, David Holmes wrote:
> Hi Thomas,
> 
> On Mon Dec 19 15:25:42 UTC 2016 Thomas Schatzl wrote:
> > 
> > On Fri, 2016-12-16 at 13:10 +1000, David Holmes wrote:
> > > 
> > > On 16/12/2016 1:06 PM, David Holmes wrote:
> > > > 
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8161993
> > > > 
> > > > JDK9 changeset:
> > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/8986e5b85e73
> > > > 
> > > > webrev: http://cr.openjdk.java.net/~dholmes/8161993/webrev.8u/
> > > > 
> > > > The changes for 8147910 are there only for reference.
> > > > 
> > > > The backport was straight-forward but couldn't apply directly
> > > > due to file/directory renaming. Also in 9 we had already
> > > > changed os::processor_count() to os::active_processor_count()
> > > > and then to os::initial_active_processor_count(), but in 8u we
> > > > skip the middle step.
> > > Nope sorry - confused myself. In both cases we go from
> > > processor_count() to initial_active_processor_count(). So it's
> > > even more direct than I thought.
> >   this backport seems to contain both the changes from JDK-8147910
> > and JDK-8161993.
> > I am a bit confused what "The changes for 8147910 are there only
> > for reference." means. Are you intending to push the webrev as is,
> > or only the JDK-8161993 part?
> > How would that work, as JDK-8161993 is based on JDK-8147910?
> > 
> > If the former, I would prefer to make two separate backports, one
> > for each. This makes it much easier to track whether a particular
> > issue has already been backported or not (or is still missing).
> > It does not seem to be that much more effort. I will review both
> > asap.
> > 
> > If this has been discussed before, and everyone agreed on that it
> > is for some reason better to combine the backports, ignore this.
> Both issues are of course being backported, so there is a changeset
> for each. The 8147910 backport applied cleanly and does not need a 
> re-review. But I kept it in the webrev, as I said, so that you could 
> refer to it for the API update.
> 
> I just need a statement that this is an accurate backport of 8161993.
> 

  looks okay.

Thanks for the clarification. I missed the part about 8147910 applying
cleanly.

Thanks,
  Thomas