Velocity
  1. Velocity
  2. VELOCITY-826

OutOfMemoryError using #parse and resource.loader.cache off

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.7
    • Fix Version/s: None
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Windows, Java 1.6, low heap (-Xmx10m)

      Description

      I was testing a template collection that uses #parse inside some #foreach, which worked all fine inside eclipse but crashed when used in the stand-alone application running with a low heap setting with an OutOfMemoryError: Java heap space. I was able overcome this by setting the <loader>.resource.loader.cache to "true".

      Still I wanted to let you know about this as it may be an indicator of a resource management issue of sorts anyway. The parsed resource is constant, with caching off it gets reported as found and loaded by the ResourceManager for each iteration (some 6000 times in the example). I understand that without caching it gets loaded every time, but why do the previously loaded instances keep occupying memory?

      When published on teh dev mailing list, it was suggested to file this bug report.

      1. VelocityOutOfMemoryTest.java
        1 kB
        Marnix Bindels
      2. script_3.vm
        0.0 kB
        Marnix Bindels
      3. script_2.vm
        0.0 kB
        Marnix Bindels
      4. script_1.vm
        0.1 kB
        Marnix Bindels
      5. heap.png
        66 kB
        Claude Brisson

        Activity

        Hide
        Marnix Bindels added a comment -

        Running the code in VelocityOutOfMemoryTest with a max heap of 10 Mb (-Xmx10m), causes an OutOfMemoryError:

        Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Unknown Source)
        at java.util.ArrayList.ensureCapacity(Unknown Source)
        at java.util.ArrayList.add(Unknown Source)
        at org.apache.velocity.runtime.directive.Parse.render(Parse.java:250)
        at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
        at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
        at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260)
        at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
        at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72)
        at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420)
        at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207)
        at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342)
        at org.apache.velocity.Template.merge(Template.java:356)
        at org.apache.velocity.Template.merge(Template.java:260)
        at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354)
        at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:320)
        at VelocityOutOfMemoryTest.main(VelocityOutOfMemoryTest.java:54)

        Show
        Marnix Bindels added a comment - Running the code in VelocityOutOfMemoryTest with a max heap of 10 Mb (-Xmx10m), causes an OutOfMemoryError: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Unknown Source) at java.util.ArrayList.ensureCapacity(Unknown Source) at java.util.ArrayList.add(Unknown Source) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:250) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.runtime.directive.Parse.render(Parse.java:260) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:72) at org.apache.velocity.runtime.directive.Foreach.render(Foreach.java:420) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:207) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:342) at org.apache.velocity.Template.merge(Template.java:356) at org.apache.velocity.Template.merge(Template.java:260) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:354) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:320) at VelocityOutOfMemoryTest.main(VelocityOutOfMemoryTest.java:54)
        Hide
        Claude Brisson added a comment -

        Heap profiling for 5,000,000 iterations.

        Show
        Claude Brisson added a comment - Heap profiling for 5,000,000 iterations.
        Hide
        Claude Brisson added a comment -

        I don't know if a specific change in the trunk fixed it, but I profiled your test case with jvisualvm and did not find any memory leak. The attached graph shows memory consumption for 5 million iterations, exhibiting peaks in each automatically triggered garbage collection.

        Tested with jdk 1.7.0_51.

        Maybe running under very low VM heap settings do need some special garbage collection strategy, but it's outside the scope of Velocity.

        Show
        Claude Brisson added a comment - I don't know if a specific change in the trunk fixed it, but I profiled your test case with jvisualvm and did not find any memory leak. The attached graph shows memory consumption for 5 million iterations, exhibiting peaks in each automatically triggered garbage collection. Tested with jdk 1.7.0_51. Maybe running under very low VM heap settings do need some special garbage collection strategy, but it's outside the scope of Velocity.

          People

          • Assignee:
            Claude Brisson
            Reporter:
            Marnix Bindels
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development