Uploaded image for project: 'jBPM'
  1. jBPM
  2. JBPM-4807

building large project multiple times with incremented versionId would consume OldGen heap gradually

    Details

      Description

      Customer reported that OldGen of JVM heap of Business Central is increasing gradually when performing "Build & Deploy" with incremented fixed version again and again like the following.

      2015-10-14T14:49:34.866+0900: 246.424: [Full GC [PSYoungGen: 576K->0K(690688K)] [ParOldGen: 450618K->223457K(1398272K)]
      2015-10-14T14:53:09.703+0900: 461.260: [Full GC [PSYoungGen: 13192K->0K(669184K)] [ParOldGen: 615858K->365108K(1398272K)]
      2015-10-14T14:57:18.456+0900: 710.013: [Full GC [PSYoungGen: 11991K->0K(670208K)] [ParOldGen: 671706K->435474K(1398272K)]
      2015-10-14T14:58:45.999+0900: 797.556: [Full GC [PSYoungGen: 28149K->0K(659456K)] [ParOldGen: 556869K->447817K(1398272K)]
      2015-10-14T15:01:51.246+0900: 982.804: [Full GC [PSYoungGen: 800K->0K(670720K)] [ParOldGen: 735296K->531696K(1398272K)]
      2015-10-14T15:04:36.893+0900: 1148.450: [Full GC [PSYoungGen: 6986K->0K(671232K)] [ParOldGen: 771705K->602130K(1398272K)]
      2015-10-14T15:06:05.781+0900: 1237.338: [Full GC [PSYoungGen: 8080K->0K(671232K)] [ParOldGen: 828260K->656776K(1398272K)]
      2015-10-14T15:09:46.687+0900: 1458.245: [Full GC [PSYoungGen: 26619K->0K(671744K)] [ParOldGen: 691569K->641541K(1398272K)]

      In this test, I build same project 40 times with incremented versionId.
      This doesn't happen if specified version is identical fixed version or SNAPSHOT version.

      Whenever building module, KieModule which is built is stored
      on memory KieRepository by the following method.

      org.drools.compiler.kie.builder.impl.KieRepositoryImpl$KieModuleRepo.store()

      Member variable 'KieModules' in class

      org.drools.compiler.kie.builder.impl.KieRepositoryImpl

      keeps these modules per version like following.

      kieModules HashMap<K,V> (id=1013)
      [0] HashMap$Entry<K,V> (id=1031)
      [1] HashMap$Entry<K,V> (id=1032)
      [2] HashMap$Entry<K,V> (id=1092)
      [3] HashMap$Entry<K,V> (id=1033)
      [4] HashMap$Entry<K,V> (id=1034)
      key "testgroup:project1" (id=1037)
      value TreeMap<K,V> (id=1038)
      [0] TreeMap$Entry<K,V> (id=1259)
      key KieRepositoryImpl$ComparableVersion (id=1265)
      canonical "(2,4)" (id=1268)
      items KieRepositoryImpl$ComparableVersion$ListItem (id=1269)
      value "2.4.0" (id=1270)
      value MemoryKieModule (id=1266)
      [1] TreeMap$Entry<K,V> (id=1261)
      key KieRepositoryImpl$ComparableVersion (id=1272)
      canonical "(2,5)" (id=1275)
      items KieRepositoryImpl$ComparableVersion$ListItem (id=1277)
      value "2.5.0" (id=1279)
      value MemoryKieModule (id=1123)
      [2] TreeMap$Entry<K,V> (id=1263)
      key KieRepositoryImpl$ComparableVersion (id=1226)
      canonical "(2,5,1)" (id=1283)
      items KieRepositoryImpl$ComparableVersion$ListItem (id=1285)
      value "2.5.1" (id=1287)
      value MemoryKieModule (id=1217)

      In above example, this project is built 3 times with 3 version(2.4.0, 2.5.0 and 2.5.1) respectively.
      Therefore, this KieModules could be getting large if the project gets built with incremented fixed version again and again, especially in case that kieModule is large (in this customer's case, kjar size is more than 4MB).

      Version-Release number of selected component (if applicable):
      6.1.x

      How reproducible:
      Build large project again and again with different versionId.

      Steps to Reproduce:
      0. prepare large project (which has large and many XLS decision tables)
      1. set versionId 1.0 and then build it
      2. set versionId 1.1 and then build it
      3. set versionID 1.2 and then build it
      :

      Actual results:
      OldGern heap is consumed gradually

      Expected results:
      OldGen heap is not consumed so much

      Additional info:

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                marco.rietveld Marco Rietveld
                Reporter:
                hiroko Hiroko Miura
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: