Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8179084

HotSpot VM fails to start when AggressiveHeap is set

    Details

    • Subcomponent:
      gc
    • Introduced In Build:
      b131
    • Introduced In Version:
      9
    • Resolved In Build:
      b168
    • CPU:
      generic
    • OS:
      generic
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.8.0_131"
        Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
        Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

        FULL OS VERSION :
        Mac OS X Sierra 10.12.4
        Darwin ID-PC14001.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

        A DESCRIPTION OF THE PROBLEM :
        When specifying -XX:+AggressiveHeap as JVM argument the VM now aborts with an error message . This used to work perfectly fine in all previous versions of the JRE/JDK

        THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

        THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

        REGRESSION. Last worked in version 8u121

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        In the simplest form even this command line aborts
        "java -XX:+AggressiveHeap -version" with error message
        "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

        In previous versions this simple cmd line would print the version. But any other combination doesn't work either.

        Additionally trying to use PrintFlagsFinal to check the actual value still causes the error.
        Many products ship with the setting in some config file out of the box (as do our own when set to production level during install)

        PrintFlagsFInal confirms that it was using 8 threads on my machine prior to u131.

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        That the virtual machine starts up with AggressiveHeap enabled without error
        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

        REPRODUCIBILITY :
        This bug can be reproduced always.

        ---------- BEGIN SOURCE ----------
        java -XX:+AggressiveHeap -version
        ---------- END SOURCE ----------

        CUSTOMER SUBMITTED WORKAROUND :
        You can work arround this by explicitly specifying a value for ParallelGCthreads only if that argument is earlier in the argument list than AggressiveHeap.

        But having to figure out why certain services/java based apps no longer start and having to edit the config files in the right location and order is annoying at best.

          Issue Links

            Activity

            webbuggrp Webbug Group created issue -
            fmatte Fairoz Matte made changes -
            Field Original Value New Value
            Assignee Fairoz Matte [ fmatte ]
            fmatte Fairoz Matte made changes -
            Status New [ 10000 ] Open [ 1 ]
            fmatte Fairoz Matte made changes -
            Labels webbug dcsfai regression reproducer-yes webbug
            fmatte Fairoz Matte made changes -
            CPU x86 [ 17004 ] generic [ 17008 ]
            fmatte Fairoz Matte made changes -
            OS os_x [ 17017 ] generic [ 17010 ]
            fmatte Fairoz Matte made changes -
            Affects Version/s 9 [ 16400 ]
            fmatte Fairoz Matte made changes -
            Priority P4 [ 4 ] P3 [ 3 ]
            fmatte Fairoz Matte made changes -
            Project Java Incidents [ 10301 ] JDK [ 10100 ]
            Key JI-9048716 JDK-8179084
            Workflow JBS Incident Workflow [ 4934632 ] JBS Workflow [ 4934632 ]
            Component/s hotspot [ 10304 ]
            Component/s hotspot [ 10707 ]
            Affects Version/s 8u131 [ 18707 ]
            Affects Version/s 9 [ 14949 ]
            Affects Version/s 9 [ 16400 ]
            Affects Version/s 8u131 [ 18703 ]
            Introduced In Build b131 [ 17818 ]
            Introduced In Version 9 [ 14949 ]
            fmatte Fairoz Matte made changes -
            Subcomponent runtime [ 543 ] runtime [ 192 ]
            fmatte Fairoz Matte made changes -
            Assignee Fairoz Matte [ fmatte ]
            fmatte Fairoz Matte made changes -
            Status Open [ 1 ] New [ 10000 ]
            dholmes David Holmes made changes -
            Assignee David Holmes [ dholmes ]
            dholmes David Holmes made changes -
            Link This issue relates to JDK-8147910 [ JDK-8147910 ]
            dholmes David Holmes made changes -
            Status New [ 10000 ] Open [ 1 ]
            dholmes David Holmes made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Understanding Cause Known [ 10000 ]
            dholmes David Holmes made changes -
            Comment [ There is something else not quite right here. The error:

            "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

            comes from Arguments::set_parallel_gc_flags(). Yet we already established that it is safe to call os::initial_processor_count() at that point as it originates in Apply::ergo().

            What we actually do is the following:

            // Arguments::parse_each_vm_init_arg()

                  // Enable parallel GC and adaptive generation sizing
                  FLAG_SET_CMDLINE(bool, UseParallelGC, true);
                  FLAG_SET_DEFAULT(ParallelGCThreads,
                                   Abstract_VM_Version::parallel_worker_threads()); <= will be zero at this point

            then later:

            // Arguments::set_gc_specific_flags()
             if (UseParallelGC || UseParallelOldGC) {
                set_parallel_gc_flags();

            which in turn does:

              FLAG_SET_DEFAULT(ParallelGCThreads,
                               Abstract_VM_Version::parallel_worker_threads()); <= SAFE TO CALL HERE!
              if (ParallelGCThreads == 0) {
                jio_fprintf(defaultStream::error_stream(),
                    "The Parallel GC can not be combined with -XX:ParallelGCThreads=0\n");
                vm_exit(1);
              }

            So how is it that we seem to be getting zero for what should be the safe call to Abstract_VM_Version::parallel_worker_threads() ?





            ]
            dholmes David Holmes made changes -
            Priority P3 [ 3 ] P2 [ 2 ]
            gtriantafill George Triantafillou made changes -
            Fix Version/s 10 [ 16302 ]
            gtriantafill George Triantafillou made changes -
            Fix Version/s 9 [ 14949 ]
            Fix Version/s 10 [ 16302 ]
            kbarrett Kim Barrett made changes -
            Assignee David Holmes [ dholmes ] Kim Barrett [ kbarrett ]
            kbarrett Kim Barrett made changes -
            Subcomponent runtime [ 192 ] gc [ 209 ]
            kbarrett Kim Barrett made changes -
            Labels dcsfai regression reproducer-yes webbug dcsfai jdk9-fix-request regression reproducer-yes webbug
            kbarrett Kim Barrett made changes -
            Labels dcsfai jdk9-fix-request regression reproducer-yes webbug dcsfai gc-pending-review jdk9-fix-request regression reproducer-yes webbug
            rcalnan Roger Calnan made changes -
            Labels dcsfai gc-pending-review jdk9-fix-request regression reproducer-yes webbug CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request regression reproducer-yes webbug
            asaha Abhijit Saha made changes -
            Labels CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request regression reproducer-yes webbug CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request regression regression_8147910 reproducer-yes webbug
            stefank Stefan Karlsson made changes -
            Description FULL PRODUCT VERSION :
            java version "1.8.0_131"
            Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
            Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

            FULL OS VERSION :
            Mac OS X Sierra 10.12.4
            Darwin ID-PC14001.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

            A DESCRIPTION OF THE PROBLEM :
            When specifying -XX:+AggressiveHeap as JVM argument the VM now aborts with an error message . This used to work perfectly fine in all previous versions of the JRE/JDK

            THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

            THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

            REGRESSION. Last worked in version 8u121

            STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
            In the simplest form even this command line aborts
            "java -XX:+AggressiveHeap -version" with error message
            "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

            In previous versions this simple cmd line would print the version. But any other combination doesn't work either.

            Additionally trying to use PrintFlagsFinal to check the actual value still causes the error.
            Many products ship with the setting in some config file out of the box (as do our own when set to production level during install)

            PrintFlagsFInal confirms that it was using 8 threads on my machine prior to u131.

            EXPECTED VERSUS ACTUAL BEHAVIOR :
            That the virtual machine starts up with AggressiveHeap enabled without error
            ERROR MESSAGES/STACK TRACES THAT OCCUR :
            "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

            REPRODUCIBILITY :
            This bug can be reproduced always.

            ---------- BEGIN SOURCE ----------
            java -XX:+AggressiveHeap -version
            ---------- END SOURCE ----------

            CUSTOMER SUBMITTED WORKAROUND :
            You can work arround this by explicitly specifying a value for ParrallelGCthreads only if that argument is earlier in the argument list than AggressiveHeap.

            But having to figure out why certain services/java based apps no longer start and having to edit the config files in the right location and order is annoying at best.

            FULL PRODUCT VERSION :
            java version "1.8.0_131"
            Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
            Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

            FULL OS VERSION :
            Mac OS X Sierra 10.12.4
            Darwin ID-PC14001.local 16.5.0 Darwin Kernel Version 16.5.0: Fri Mar 3 16:52:33 PST 2017; root:xnu-3789.51.2~3/RELEASE_X86_64 x86_64

            A DESCRIPTION OF THE PROBLEM :
            When specifying -XX:+AggressiveHeap as JVM argument the VM now aborts with an error message . This used to work perfectly fine in all previous versions of the JRE/JDK

            THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: Yes

            THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

            REGRESSION. Last worked in version 8u121

            STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
            In the simplest form even this command line aborts
            "java -XX:+AggressiveHeap -version" with error message
            "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

            In previous versions this simple cmd line would print the version. But any other combination doesn't work either.

            Additionally trying to use PrintFlagsFinal to check the actual value still causes the error.
            Many products ship with the setting in some config file out of the box (as do our own when set to production level during install)

            PrintFlagsFInal confirms that it was using 8 threads on my machine prior to u131.

            EXPECTED VERSUS ACTUAL BEHAVIOR :
            That the virtual machine starts up with AggressiveHeap enabled without error
            ERROR MESSAGES/STACK TRACES THAT OCCUR :
            "The Parallel GC can not be combined with -XX:ParallelGCThreads=0"

            REPRODUCIBILITY :
            This bug can be reproduced always.

            ---------- BEGIN SOURCE ----------
            java -XX:+AggressiveHeap -version
            ---------- END SOURCE ----------

            CUSTOMER SUBMITTED WORKAROUND :
            You can work arround this by explicitly specifying a value for ParallelGCthreads only if that argument is earlier in the argument list than AggressiveHeap.

            But having to figure out why certain services/java based apps no longer start and having to edit the config files in the right location and order is annoying at best.

            mikael Mikael Vidstedt made changes -
            Labels CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request regression regression_8147910 reproducer-yes webbug CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            hgupdate HG Updates made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolved In Build team [ 17324 ]
            Understanding Cause Known [ 10000 ]
            Resolution Fixed [ 1 ]
            pgupta Praveen Gupta made changes -
            Labels CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug CPU17_03-critical-SQE-OK CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            ydagra Yashi Dagra made changes -
            Labels CPU17_03-critical-SQE-OK CPU17_03-critical-request dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug CPU17_03-critical-SQE-OK CPU17_03-critical-approved dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            wyandi Winston Yandi made changes -
            Labels CPU17_03-critical-SQE-OK CPU17_03-critical-approved dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug CPU17_03-critical-SQE-OK CPU17_03-critical-pre-approval dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8179469 [ JDK-8179469 ]
            hgupdate HG Updates made changes -
            Resolved In Build team [ 17324 ] master [ 18256 ]
            hgupdate HG Updates made changes -
            Resolved In Build master [ 18256 ] b168 [ 19718 ]
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8179757 [ JDK-8179757 ]
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8183670 [ JDK-8183670 ]
            pmohan Praveen Mohan made changes -
            Labels CPU17_03-critical-SQE-OK CPU17_03-critical-pre-approval dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug CPU17_03-critical-SQE-OK CPU17_03-critical-pre-approval CPU17_04-critical-SQE-OK dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            ydagra Yashi Dagra made changes -
            Labels CPU17_03-critical-SQE-OK CPU17_03-critical-pre-approval CPU17_04-critical-SQE-OK dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug CPU17_03-critical-SQE-OK CPU17_03-critical-pre-approval CPU17_04-critical-SQE-OK CPU17_04-critical-approved dcsfai gc-pending-review jdk9-fix-request jdk9-fix-yes regression regression_8147910 reproducer-yes webbug
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8185307 [ JDK-8185307 ]
            lmesnik Leonid Mesnik made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Verification Verified [ 17000 ]
            hgupdate HG Updates made changes -
            Link This issue backported by JDK-8185726 [ JDK-8185726 ]

              People

              • Assignee:
                kbarrett Kim Barrett
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                10 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: