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

Message "Error occurred during initialization of VM" on boxes with lots of RAM

    Details

    • Subcomponent:
      gc
    • Resolved In Build:
      b85
    • CPU:
      x86
    • OS:
      linux_redhat_5.0

      Backports

        Description

        FULL PRODUCT VERSION :
        ./bin/java -Xmx256M -version
        java version "1.6.0_29"
        Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
        Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)


        ADDITIONAL OS VERSION INFORMATION :
        Linux wn-car-027.farm.nikhef.nl 2.6.18-274.3.1.el5 #1 SMP Tue Sep 6 20:13:52 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux

        (CentOS 5.7)

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        Oracle Java 6u29
        (same bug applies to OpenJDK 1.6.0)

        A DESCRIPTION OF THE PROBLEM :
        the latest&greatest worker nodes have 12 cores and 48 GB of RAM ; we
        offer a maximum 12 jobs slots on these worker nodes, in order to
        accomodate small and large jobs (users can requests 1 - 12 cores). To
        ensure that the different jobs don't interfere with each other we also
        set a VMEM limit for each job slot. The current VMEM limit is 48 / 12 =
        4 GB RAM per job slot. Each single core job that starts has a 'ulimit
        -v' of 4,000,000 .

        On these boxes java refuses to start:

        $ java -version
        Error occurred during initialization of VM
        Could not reserve enough space for object heap
        Could not create the Java virtual machine.

        After some debugging I found that this is caused by the default maximum
        heap size which java allocates: it scans /proc/meminfo to extrac the
        amount of RAM installed and divides it by 4 ; an 'strace' shows that
        indeed 'java' tries to do an 'mmap' call for 12 GB of RAM !

        A work around is to always specify '-Xmx2GB' or something similar but
        this does not work for all software that we use , plus , I find it
        annoying that I have to tell this to all my users.

        What I would like to see is a system-wide setting for the initial
        maximum heap size, so that
          java -version
        "just works" . Is this possible?


        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        - take a box with 8 GB of ram or more
        - set
          ulimit -v 1600000
        - run
          java -version

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        java version "1.6.0_29"
        Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
        Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)

        ACTUAL -
        Error occurred during initialization of VM
        Could not reserve enough space for object heap
        Could not create the Java virtual machine.


        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        Error occurred during initialization of VM
        Could not reserve enough space for object heap
        Could not create the Java virtual machine.


        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        always specify
          -Xmx<number>

        this is not always possible , however.

          Issue Links

            Activity

            Hide
            ksrini Kumar Srinivasan added a comment -
            BT2:EVALUATION

            It is not clear to me what is being asked. The customer is asking for
            a system-wide configuration file to set the starting heap size ? to print
            -version at the least and then what ?

            But as far as I can tell the the GC reserves the space up front to
            ensure contiguous memory, due to server VM GC ergonomics.

            Nevertheless, I am reassigning to the GC team for their evaluation.
            Show
            ksrini Kumar Srinivasan added a comment - BT2:EVALUATION It is not clear to me what is being asked. The customer is asking for a system-wide configuration file to set the starting heap size ? to print -version at the least and then what ? But as far as I can tell the the GC reserves the space up front to ensure contiguous memory, due to server VM GC ergonomics. Nevertheless, I am reassigning to the GC team for their evaluation.
            Hide
            jcoomes John Coomes added a comment -
            BT2:EVALUATION

            The JVM should check the amount of address space available to the user running the application (getrlimit(RLIMIT_AS) on solaris/linux, not sure of the equivalent on windows), and use that as an additional constraint on the size of the heap requested. On solaris, RLIMIT_VMEM should also be considered.
            Show
            jcoomes John Coomes added a comment - BT2:EVALUATION The JVM should check the amount of address space available to the user running the application (getrlimit(RLIMIT_AS) on solaris/linux, not sure of the equivalent on windows), and use that as an additional constraint on the size of the heap requested. On solaris, RLIMIT_VMEM should also be considered.
            Hide
            dholmes David Holmes added a comment -
            BT2:EVALUATION

            It is not, I believe, the "java -version" that is the issue, that is just a way to demonstrate the problem. The user wants a way to control/set the value of -Xmx on all JVMs launched on a machine.

            Use of _JAVA_OPTIONS may be of assistance.
            Show
            dholmes David Holmes added a comment - BT2:EVALUATION It is not, I believe, the "java -version" that is the issue, that is just a way to demonstrate the problem. The user wants a way to control/set the value of -Xmx on all JVMs launched on a machine. Use of _JAVA_OPTIONS may be of assistance.
            Hide
            dholmes David Holmes added a comment -
            See also JDK-6374896 - as per John's comments it seems like GC ergonomics needs to be accounting for imposed process limits.
            Show
            dholmes David Holmes added a comment - See also JDK-6374896 - as per John's comments it seems like GC ergonomics needs to be accounting for imposed process limits.
            Hide
            tschatzl Thomas Schatzl added a comment -
            Also affects hs25
            Show
            tschatzl Thomas Schatzl added a comment - Also affects hs25
            Hide
            tschatzl Thomas Schatzl added a comment -
            Proposed fix: Use maximum virtual memory sizes as reported by the OSes to limit max heap size
            Show
            tschatzl Thomas Schatzl added a comment - Proposed fix: Use maximum virtual memory sizes as reported by the OSes to limit max heap size
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/754c24457b20
            User: amurillo
            Date: 2013-04-09 21:34:29 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/754c24457b20 User: amurillo Date: 2013-04-09 21:34:29 +0000

              People

              • Assignee:
                tschatzl Thomas Schatzl
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: