RFR: 6979279: remove special-case code for ParallelGCThreads==0
jesper.wilhelmsson at oracle.com
Wed Oct 8 13:44:30 UTC 2014
Looks good in general. Two comments:
* In compactibleFreeListSpace.cpp the code:
630 MutexLockerEx x(parDictionaryAllocLock(),
was previously executed for all values of ParallelGCThreads > 0, now it is not
executed when ParallelGCThreads = 1. Seems legit, just want to make sure this is
intentional. Are there any side effects to creating this lock that is expected
to happen for PGCT = 1?
* In g1HotCardCache you remove the variable _hot_cache_par_chunk_size and read
directly from the flag in G1HotCardCache::drain() . I would prefer to keep the
variable and only read from the flag during initialization. I think it would be
nice if we were moving towards not reading directly from command line flags
during GC. There have been a few cases lately where we have been in need of
changing settings for the GC at runtime (when making flags manageable for
instance) and I think we will see more of this in the future if we want to see a
GC that can behave differently in different situations. It is a lot easier to do
this if the flags can be changed at any time without needing to worry about them
being read during GC.
Marcus Larsson skrev 8/10/14 09:56:
> Can I please have reviews for the following patch removing the special-case
> code used when ParallelGCThreads is 0. A recent change  forbidding this
> flag to be set to 0 turns this special handling into dead code, which should
> be removed.
> Functions with two interfaces for single threaded or parallel execution used
> exclusively in these cases have been merged to a single parallel version (for
> example G1RemSet's scrub and scrub_par).
> - jprt
> - Aurora
> - Weblogic
> - runThese
> - Kitchensink
> - jtreg
> - VM GC nightly
> : https://bugs.openjdk.java.net/browse/JDK-8059527
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev