RFR: 8150518: G1 GC crashes at G1CollectedHeap::do_collection_pause_at_safepoint(double)
Thomas Schatzl
thomas.schatzl at oracle.com
Thu Mar 10 20:46:45 UTC 2016
Hi,
On Thu, 2016-03-10 at 15:42 -0500, Kim Barrett wrote:
> > On Mar 10, 2016, at 12:21 PM, Jon Masamitsu <
> > jon.masamitsu at oracle.com> wrote:
> >
> >
> >
[...]
> The retry setting to parallel_worker_threads() again code dates back
> to the initial G1 checkin. Hard to know what was intended.
>
> The current jdk9 code does not have that: it looks like
>
> FLAG_SET_DEFAULT(ParallelGCThreads,
> Abstract_VM_Version::parallel_worker_threads());
> if (ParallelGCThreads == 0) {
> assert(!FLAG_IS_DEFAULT(ParallelGCThreads), "The default value
> for ParallelGCThreads should not be 0.");
> vm_exit_during_initialization("The flag -XX:+UseG1GC can not be
> combined with -XX:ParallelGCThreads=0", NULL);
> }
>
> This proposed change is for jdk8u-something, correct?
>
> In jdk9 G1 does not support ParallelGCThreads == 0 at all, as can be
> seen above. Making use of that decision, a cleanup pass was made
> that eliminated a whole bunch of “if (ParallelGCThreads == 0) then
> pretend it’s 1 or do some other special thing” code. The backport of
> 8017462 to 8u72 (i.e. 8149347) looks like it might not have taken
> that into account. For example,
just some historical note: in 8u, ParallelGCThreads == 0 means "use the
VM thread, single threaded", and ParallelGCThreads == 1 means use a
single worker thread.
In jdk9 we removed that option to use the vm thread in a single
threaded way.
We did not backport that change because of potential performance impact
(whatever that might be).
Thanks,
Thomas
More information about the hotspot-runtime-dev
mailing list