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

Thomas Schatzl thomas.schatzl at oracle.com
Mon Dec 19 15:25:42 UTC 2016


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.


More information about the hotspot-gc-dev mailing list