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