RFR (smallish?) 8061611: Remove deprecated command line flags

Bengt Rutisson bengt.rutisson at oracle.com
Mon Nov 24 11:55:12 UTC 2014

Hi Derek,

Sorry for taking so long to review this.

On 2014-11-18 17:40, Derek White wrote:
> Hi Team,
> First review request. Please let me know if I've forgotten something 
> or have gone completely off the rails.
> The main point of this bug is to remove deprecated -XX options which 
> are alias for other options.
> The only complicated part is that one case, 
> /CMSParPromoteBlocksToClaim/ was not a true alias for /OldPLABSize/ 
> but a parallel option with different defaults that were synchronized 
> in ergo processing. This fix removes the /CMSParPromoteBlocksToClaim 
> /variable but preserves using different defaults in the CMS case.
> Also in this fix I added warning messages to several remaining 
> undocumented command line options aliases. This should ease removal of 
> these options in the future
> CMSMarkStackSize ==> MarkStackSize        (MarkStackSize not documented either, but came in jdk6)
> G1MarkStackSize  ==> MarkStackSize
> CMSMarkStackSizeMax ==> MarkStackSizeMax  (MarkStackSizeMax not documented either)
> ParallelMarkingThreads =>  ConcGCThreads  (ConcGCThreads came in jdk6)
> ParallelCMSThreads     ==> ConcGCThread
> Thanks,
>  - Derek
> *Webrev*: http://cr.openjdk.java.net/~drwhite/8061611/webrev.00/
> *Bug*: https://bugs.openjdk.java.net/browse/JDK-8061611

Looks good to me. One minor nit regarding the naming of the new 
constants that you introduce:

  682   static const int defaultDynamicOldPLABSize = 16;
  683   static const int defaultStaticOldPLABSize  = 50;

HotSpot does not have a common guideline for how to name constants. 
There are at least three widely used naming standards:

- Like an instance variable: _default_dynamic_old_plab_size
- Like a flag: DefaultDynamicOldPLABSize

I think it is hard to say which one is "standard" but I would prefer if 
we don't introduce yet another naming standard for constants. Do you 
mind changing to one of these? Personally I prefer the last one (the 
"Like a flag" version).


> *Testing*:
> jprt:
>     Saw 1-2 intermittent failures that went away on retesting - hangs 
> and timeouts.
> refworkload:
>     no differences
> jtreg: Saw a few unexplained results. Not sure if typical or not:
>             Execution failed: `main' threw exception:
>             java.lang.Exception: jmap -heap exited with error code: 1
>       * gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
>         <http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.jtr>:
>         Checks that jmap -heap contains the flag CompressedClassSpaceSize
>             Program
>             `/export/users/drwhite/test-builds/j2sdk-image.11.17.2014/bin/java'
>             interrupted! (timed out?)
>       * closed/runtime/AppCDS/SharedArchiveConsistency.java
>         <http://oklahoma.us.oracle.com/net/bussund0416//export/users/drwhite/hs-gc-mine/hotspot/test/JTwork/closed/runtime/AppCDS/SharedArchiveConsistency.jtr>:
>         SharedArchiveConsistency
>     Plus a bunch of tests that are labelled "ignored".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20141124/affd8a3f/attachment-0001.html>

More information about the hotspot-gc-dev mailing list