Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-3692

FATAL: Java heap space

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: crap4j-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: Linux
    • Similar Issues:

      Description

      We seem to be having troubles with heap space and the plugin.

      [CRAP4J] Collecting Crap4J analysis files...
      [CRAP4J] Searching for report files within checkout/_DIST/reports/crap/report.xml
      [CRAP4J] Using the new FileSetBuilder
      FATAL: Java heap space
      java.lang.OutOfMemoryError: Java heap space

      Crap itself seems to be finishing, but the plugin is doing something to use up
      heap space. It's intermittent, of course. We can increase heap size for the
      build process, but I thought I'd ask here for alternative ideas.

      thanks

        Attachments

          Activity

          Hide
          dlindner dlindner added a comment -

          Hi drewyaus,

          thank you for this issue. As there is a workaround (throw more memory on it), i
          think its not a high pressure issue.

          The Crap4J plugin uses an internal data model that is stored in memory. I think
          i can improve the deconstruction of the model once data isn't used anymore.
          Right now, the model gets completly built and processed only afterwards.

          Just to have a guideline of your memory consumption: how many classes/methods
          are in your report.xml? Is the plugin working on a 64bit JVM? How much memory
          was (or might have been) allocated before the OOME?

          Show
          dlindner dlindner added a comment - Hi drewyaus, thank you for this issue. As there is a workaround (throw more memory on it), i think its not a high pressure issue. The Crap4J plugin uses an internal data model that is stored in memory. I think i can improve the deconstruction of the model once data isn't used anymore. Right now, the model gets completly built and processed only afterwards. Just to have a guideline of your memory consumption: how many classes/methods are in your report.xml? Is the plugin working on a 64bit JVM? How much memory was (or might have been) allocated before the OOME?
          Hide
          drewyaus drewyaus added a comment -

          Thanks for response. We have a lot of applications in Hudson, so i wanted to
          check before we start upping the memory for all of them.

          We have 8203 methods. Not sure how many classes. JVM runs in 32bit mode. We
          don't specify any memory options, so it must be the default for our build server
          (x86_64 GNU/Linux).

          Show
          drewyaus drewyaus added a comment - Thanks for response. We have a lot of applications in Hudson, so i wanted to check before we start upping the memory for all of them. We have 8203 methods. Not sure how many classes. JVM runs in 32bit mode. We don't specify any memory options, so it must be the default for our build server (x86_64 GNU/Linux).
          Hide
          dlindner dlindner added a comment -

          Hi drewyaus,

          i worked on this issue a bit and was able to lower the memory consumption. The
          layer that reads the crap4j data was written as a generic API, but most of its
          functionality isn't used within the crap4j plugin. After disabling it, there is
          no more wasted memory.

          I will append a preview version of the plugin that is under testing right now.
          If you don't mind to add your testing expertise, you're welcome.
          I haven't done memory benchmarks yet.

          Side note:
          If you wonder what other tools are using this API, have a look at the crapmap.
          http://schneide.wordpress.com/2009/06/15/a-guide-through-the-swamp-the-crapmap/

          Show
          dlindner dlindner added a comment - Hi drewyaus, i worked on this issue a bit and was able to lower the memory consumption. The layer that reads the crap4j data was written as a generic API, but most of its functionality isn't used within the crap4j plugin. After disabling it, there is no more wasted memory. I will append a preview version of the plugin that is under testing right now. If you don't mind to add your testing expertise, you're welcome. I haven't done memory benchmarks yet. Side note: If you wonder what other tools are using this API, have a look at the crapmap. http://schneide.wordpress.com/2009/06/15/a-guide-through-the-swamp-the-crapmap/
          Hide
          dlindner dlindner added a comment -

          Created an attachment (id=771)
          version 0.7-SNAPSHOT of crap4j plugin. lower memory footprint

          Show
          dlindner dlindner added a comment - Created an attachment (id=771) version 0.7-SNAPSHOT of crap4j plugin. lower memory footprint
          Hide
          evernat evernat added a comment - - edited

          Hi dlindner and drewyaus,

          An improvement was made on this issue and it is now stale for a long time.
          I suggest closing the issue as fixed.
          Are you ok?

          Thanks for your attention

          Show
          evernat evernat added a comment - - edited Hi dlindner and drewyaus, An improvement was made on this issue and it is now stale for a long time. I suggest closing the issue as fixed. Are you ok? Thanks for your attention
          Hide
          dlindner dlindner added a comment -

          Workaround should fix this. Reopen or create a new issue if you still have trouble with memory consumption.

          Show
          dlindner dlindner added a comment - Workaround should fix this. Reopen or create a new issue if you still have trouble with memory consumption.

            People

            • Assignee:
              dlindner dlindner
              Reporter:
              drewyaus drewyaus
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: