search

opensha / opensha-dev

Development sandbox for OpenSHA project
BSD 3-Clause "New" or "Revised" License
3 stars 5 forks source link

Java GC overhead limit exceeded in DownDipTestRupSetBuilder.java #28

Closed chrisbc closed 4 years ago

chrisbc commented 4 years ago

Is this expected in https://github.com/opensha/opensha-dev/blob/master/src/scratch/kevin/ucerf3/downDipSubSectTest/DownDipTestRupSetBuilder.java

With Eclipse VM config set to -Xms512M -Xmx2g 

along-strike distance: tot=98.50121, each: 3.2833736
down-dip vertical distance: tot=30.0, each: 1.5
down-dip horizontal distance: tot=82.424324, each: 4.1212163
down-dip width: tot=87.714134, each: 4.3857064
Have 600 sub-sections for Test SubSect Down-Dip Fault
Have 614 sub-sections in total
Building connections for 614 subsections on 2 parent sections
Found 1 possible section connections
    New largest rup has 10 subsections with 0 jumps and 0 splays. 10 rups in total
    New largest rup has 20 subsections with 0 jumps and 0 splays. 20 rups in total
    New largest rup has 30 subsections with 0 jumps and 0 splays. 30 rups in total
    New largest rup has 40 subsections with 0 jumps and 0 splays. 50 rups in total
    New largest rup has 50 subsections with 0 jumps and 0 splays. 55 rups in total
    New largest rup has 60 subsections with 1 jumps and 0 splays. 63 rups in total
    New largest rup has 90 subsections with 0 jumps and 0 splays. 104 rups in total
    New largest rup has 100 subsections with 0 jumps and 0 splays. 129 rups in total
    New largest rup has 120 subsections with 0 jumps and 0 splays. 134 rups in total
    New largest rup has 130 subsections with 0 jumps and 0 splays. 160 rups in total
    New largest rup has 140 subsections with 0 jumps and 0 splays. 162 rups in total
    New largest rup has 150 subsections with 0 jumps and 0 splays. 164 rups in total
    New largest rup has 180 subsections with 0 jumps and 0 splays. 194 rups in total
    New largest rup has 210 subsections with 0 jumps and 0 splays. 224 rups in total
    New largest rup has 240 subsections with 0 jumps and 0 splays. 254 rups in total
    New largest rup has 270 subsections with 0 jumps and 0 splays. 284 rups in total
    New largest rup has 280 subsections with 0 jumps and 0 splays. 312 rups in total
    New largest rup has 290 subsections with 0 jumps and 0 splays. 313 rups in total
    New largest rup has 300 subsections with 0 jumps and 0 splays. 314 rups in total
    New largest rup has 330 subsections with 0 jumps and 0 splays. 344 rups in total
    New largest rup has 360 subsections with 0 jumps and 0 splays. 374 rups in total
    New largest rup has 390 subsections with 0 jumps and 0 splays. 404 rups in total
    New largest rup has 420 subsections with 0 jumps and 0 splays. 434 rups in total
    New largest rup has 450 subsections with 0 jumps and 0 splays. 464 rups in total
    New largest rup has 480 subsections with 0 jumps and 0 splays. 494 rups in total
    New largest rup has 510 subsections with 0 jumps and 0 splays. 524 rups in total
    New largest rup has 540 subsections with 0 jumps and 0 splays. 554 rups in total
    New largest rup has 570 subsections with 0 jumps and 0 splays. 584 rups in total
    New largest rup has 580 subsections with 0 jumps and 0 splays. 613 rups in total
    New largest rup has 600 subsections with 0 jumps and 0 splays. 614 rups in total
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.HashMap$KeySet.iterator(HashMap.java:917)
    at java.util.HashSet.iterator(HashSet.java:173)
    at com.google.common.collect.AbstractMapBasedMultimap.iteratorOrListIterator(AbstractMapBasedMultimap.java:585)
    at com.google.common.collect.AbstractMapBasedMultimap.access$100(AbstractMapBasedMultimap.java:89)
    at com.google.common.collect.AbstractMapBasedMultimap$WrappedCollection$WrappedIterator.<init>(AbstractMapBasedMultimap.java:440)
    at com.google.common.collect.AbstractMapBasedMultimap$WrappedCollection.iterator(AbstractMapBasedMultimap.java:425)
    at scratch.kevin.ucerf3.downDipSubSectTest.DownDipTestPermutationStrategy.buildRectangularPermutation(DownDipTestPermutationStrategy.java:129)
    at scratch.kevin.ucerf3.downDipSubSectTest.DownDipTestPermutationStrategy.calcPermutations(DownDipTestPermutationStrategy.java:50)
    at org.opensha.sha.earthquake.faultSysSolution.ruptures.strategies.CachedClusterPermutationStrategy.getPermutations(CachedClusterPermutationStrategy.java:30)
    at org.opensha.sha.earthquake.faultSysSolution.ruptures.ClusterRuptureBuilder.build(ClusterRuptureBuilder.java:148)
    at scratch.kevin.ucerf3.downDipSubSectTest.DownDipTestRupSetBuilder.main(DownDipTestRupSetBuilder.java:111)

WORKAROUND

kevinmilner commented 4 years ago

Yeah that's expected, rupture building uses up a lot of memory. When you get to doing the real thing with a large subduction zone, you will likely need much more that 4 GB unless you're have even stricter permutation rules than currently implemented (I have 64 GB on my machine). I did remove the caching from the permutation strategy though, which reduces the memory footprint a little (and it wasn't speeding things up helping here). I also committed a few performance improvements to the main rupture building code in the ucerf3 repository