JDK-4751308 : Interaction of combinations of potentially conflicting flags is confusing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2
  • Priority: P5
  • Status: Closed
  • Resolution: Other
  • OS: generic
  • CPU: generic
  • Submitted: 2002-09-21
  • Updated: 2012-10-03
  • Resolved: 2012-10-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisResolved
Related Reports
Relates :  
Description
This bug will become moot if/when we stop exposing flags to the
customer that allow them to choose specific (sets of) collectors.

As it currently stands, the following is true of the following set of
flags that decide the choice of collector(s):
   -Xincgc, -Xconcgc, -XX:+UseParallelGC, -XX:+UseParNewGC


. -XX:+UseParallelGC overrides all other flags in the above set
. -Xingc overrides all flags other than -XX:+UseParallelGC
. -Xconcgc and -XX:+UseParNewGC don't override each other and
  can be used in all combinations except when overridden by the
  flags in earlier bullets

In addition there may be potentially interactions with the
ParallelGCThreads flag (and potentially other such "shared flags")
which may need to be looked at.

This bug is being filed as a place holder to try and reduce potential
customer confusion wrt these GC flags.

Note that in general this is a problem not just with GC flags
but all the myriad XX flags. At some point it might be a good idea to
think through these interactions and try and work towards reducing
or at least making clear rules on these interactions. That however
is, in general, easier said than done.

However, for the handful of GC flags mentioned above it may be
relatively straightforward to devise and enforce a uniform rule
(for instance one based on the order of potentially conflicting
flags on the command-line) regarding interactions between them.
It may be a good ides to do at least that.

Comments
Been in resolved state for more than ten years. Closing.
03-10-2012

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004

EVALUATION see comments section.
11-06-2004

SUGGESTED FIX ------- arguments.cpp ------- 827a828,844 > // Ensure that the user has not selected conflicting sets > // of collectors. [Note: this check is merely a user convenience; > // collectors over-ride each other so that only a non-conflicting > // set is selected; however what the user gets is not what they > // may have expected from the combination they asked for. It's > // better to reduce user confusion by not allowing them to > // select conflicting combinations. > bool CMSParNew = UseConcMarkSweepGC || UseParNewGC; > if ((CMSParNew && (UseTrainGC || UseParallelGC)) || > (UseTrainGC && (UseParallelGC || CMSParNew)) || > (UseParallelGC && (CMSParNew || UseTrainGC))) { > jio_fprintf(stderr, > " Conflicting collector combinations; please refer to\n" > " the release notes for the combinations allowed\n"); > status = false; > } > ###@###.### 2002-10-26: modified upon a code review; fix putback to gc_baseline: Date: Fri, 25 Oct 2002 22:07:32 -0700 (PDT) From: "Y. S. Ramakrishna" <###@###.###> Subject: Code Manager notification (putback-to) To: ###@###.### Event: putback-to Parent workspace: /net/jano/export/disk05/hotspot/ws/main/gc_baseline (jano:/export/disk05/hotspot/ws/main/gc_baseline) Child workspace: /export/imgr_home/ws/20021025203603.ysr.pRemark3 (balvenie:/export/imgr_home/ws/20021025203603.ysr.pRemark3) User: ysr Comment: Original workspace: neeraja:/net/spot/archive02/ysr/pRemark3 Parent workspace: /net/jano/export/disk05/hotspot/ws/main/gc_baseline Submitter: ysr imgr data: /net/balvenie.sfbay/export/imgr_home/archive/main/gc_baseline/20021025203603.ysr.pRemark3 4735823 CMS: Perf: implement parallel remark 4767178 CMS: Perf: rescan is redundant if mark was stop-world 4768725 CMS: Perf: specialize oop_oop_iterate for stop-world closures 4751308 Interaction of combinations of potentially conflicting flags is confusing (eou) http://analemma.sfbay/net/spot/archive02/ysr/pRemark3/webrev ------------------------------------------------- Fixed: 4735823 CMS: Perf: implement parallel remark When CMSRemarkEnabled flag is on and ParNewGC is chosen for the young generation, the final checkpoint phase (aka the remark phase) of the CMS collection is executed by several threads in parallel (equal in number to the value of ParallelGCThreads which defaults to the number of CPU's). All of the "remark" work, which involves rescanning grey objects and completing the transitive closure to find and blacken any residual white or grey objects is done in parallel as a CMSParRemarkTask, being a subtype of AbstractGangTask utility. Each parallel task first processes the root sets into the CMS heap, using the parallel version of process_strong_roots() in which groups of roots are claimed sequentially by the parallel workers. The young generation is treated as a monolithic root group and is a known potential bottleneck to scaling especially as the young generation size is scaled up. (Parallelizing the young generation rescan will, however, not be undertaken for Mantis as we believe we have adequate performance for a certain key customer, and because the dev-freeze date is close.) Then the card table and the mod-union-table rescan occurs with the rescan work overpartitioned and sequentially claimed by parallel workers. Two new closures are introduced, being parallel avatars of closures used in sequential code. The salient difference is that the former use work queues that allow work stealing, as well as using CAS for marking the bit-map. No attempt is currently made to uniquely claim white objects to grey during the transitive marking phase and this may lead to some amount of redundant work. (We hope to measure the amount of redundant work to see if it may be worth trying to avoid that redundancy.) Once a thread has completed all the work that ut had claimed in the previous "phases", an otherwise idle thread proceeds to steal work (i.e. grey objects) from other threads. Some of the sequential remark code and one or two closures used therein had to be restructured somewhat to allow maximal sharing and to allow the parallel code to be cleanly broken out from the main work methods. Also included in are a couple of minor clean-ups as described in the sccs comments of individual files in the webrev (VerifyGCStartAt support in CMS, refs_discovery_is_mt attribute in generation, correct prefetch type for a couple of CMS closures, some locking verification encapsulation and simplification for CMS etc.) Nortel remark pauses were reduced by a factor of roughly 2X on a 4X machine. Smaller improvements were seen with spec and jbb, but more careful measurements will be made. From broswing the verbosegc data, the main bottleneck at this point appears to be the young gen rescan. Acknowledgments: Ross and Detlefs for useful early discussions; Detlefs for creating an excellent infrastructure of parallel collection utilities which made implementing CMS parallel remark quite simple; Jon for useful Nortel know-how and experiments. Reviewed by: John Coomes(*1), Jon Masamitsu(*1), Ross Knippel(*2) Fix verified (y/n): y Verification testing: (CMS+ParNew, C1, unless otherwise stated): . spec with Verify<Before,After,During>GC . refWorkload: U{{debug}X{C1},{product}X{C1,C2}} . VMark: {debug,product} . VTest: CMS+DefNew X {debug,product} . Nortel (product,C2) . GCOld (debug,product) . GCTests (product, c1) VTest:CMS+ParNew fails with 4738796 under investigation ------------------------------------------------- Fixed: 4767178 CMS: Perf: rescan is redundant if mark was stop-world When mark is at a stop-world, there is no need for a rescan phase because the object graph has not mutated during or since the mark. This would help speed up potential forgeround collections when CMS is deployed but faces a concurrent mode failure or when a full gc is called. Reviewed by: Ross Knippel Fix verified (y/n): y Verification testing: (CMS+ParNew, C1, unless otherwise stated): . spec with Verify<Before,After,During>GC . refWorkload: U{{debug}X{C1},{product}X{C1,C2}} ------------------------------------------------- Fixed: 4768725 CMS: Perf: specialize oop_oop_iterate for stop-world closures Specialized oop_oop_iterate for closures used in remark phase (the initial mark phase is pretty short and doesn't at this time merit the same treatment): [Par_]{MarkRefsIntoAndScanClosure,PushAndMarkClosure} Reviewed by: John Coomes, Peter Kessler Fix verified (y/n): y Verification testing: (CMS+ParNew, C1, unless otherwise stated): . spec with Verify<Before,After,During>GC . refWorkload -------------------------------------------------- Fixed: 4751308 Interaction of combinations of potentially conflicting flags is confusing (eou) Added code in Arguments::check_vm_args_consistency() that merely checks that of the 4 collector options (UseParallelGC, UseParNewGC, UseTrainGC and UseConcMarkSweepGC) only allowed combinations are selected; refers the user to the release notes in case an illegal combination is selected. Note that illegal combinations of options would give you a legal configuration, only it might not be what you asked for, since these flags override each other in unintuitive ways, as documented in the bug report and evident from the current implementation. Reviewed by: John Coomes, Peter Kessler Fix verified (y/n): y Verification testing: Exercised java -version with various combinations, both legal and illegal, of collectors. passed linux i486 product SPECjvm98 GeoMean 34.25 57.92 passed linux i486 product1 SPECjvm98 GeoMean 44.27 49.86 passed linux i486 productcore SPECjvm98 GeoMean 97.26 97.26 passed linux ia64 productcore SPECjvm98 GeoMean 27.00 27.00 passed solaris i486 product SPECjvm98 GeoMean 34.03 57.75 passed solaris i486 product1 SPECjvm98 GeoMean 44.54 49.23 passed solaris i486 productcore SPECjvm98 GeoMean 98.49 98.49 passed solaris sparc product SPECjvm98 GeoMean 23.21 35.38 passed solaris sparc product1 SPECjvm98 GeoMean 23.26 25.80 passed solaris sparc productcore SPECjvm98 GeoMean 38.42 38.42 passed solaris sparcv9 product SPECjvm98 GeoMean 23.14 36.44 passed solaris sparcv9 productcore SPECjvm98 GeoMean 40.05 40.05 passed windows i486 compiler2 SPECjvm98 GeoMean 45.75 101.59 passed windows i486 compiler1 SPECjvm98 GeoMean 61.39 74.19 passed windows i486 core SPECjvm98 GeoMean 121.12 121.12 passed windows ia64 core SPECjvm98 GeoMean 17.98 17.98 Files: update: src/share/vm/includeDB_core update: src/share/vm/memory/compactibleFreeListSpace.cpp update: src/share/vm/memory/compactibleFreeListSpace.hpp update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/concurrentMarkSweepGeneration.hpp update: src/share/vm/memory/concurrentMarkSweepGeneration.inline.hpp update: src/share/vm/memory/genOopClosures.hpp update: src/share/vm/memory/genOopClosures.inline.hpp update: src/share/vm/memory/generation.cpp update: src/share/vm/memory/generation.hpp update: src/share/vm/memory/iterator.hpp update: src/share/vm/memory/parNewGeneration.hpp update: src/share/vm/memory/referenceProcessor.hpp update: src/share/vm/memory/sharedHeap.cpp update: src/share/vm/memory/specialized_oop_closures.hpp update: src/share/vm/memory/universe.cpp update: src/share/vm/oops/klassKlass.cpp update: src/share/vm/runtime/arguments.cpp update: src/share/vm/runtime/globals.hpp update: src/share/vm/runtime/init.cpp update: src/share/vm/utilities/bitMap.cpp update: src/share/vm/utilities/bitMap.hpp create: deleted_files/src/share/vm/memory/cmsLockVerify.cpp create: deleted_files/src/share/vm/memory/cmsLockVerify.hpp create: src/share/vm/memory/cmsLockVerifier.cpp create: src/share/vm/memory/cmsLockVerifier.hpp Examined files: 2610 Contents Summary: 4 create 22 update 2584 no action (unchanged)
11-06-2004