Build fails with java.lang.OutOfMemoryError for large project

[gregmcgowan]

I attempted to use scrabbard on our project and I got an java.lang.OutOfMemoryError

The project is quite large so I kind of expected it. I've included the stacktrace here and can provide other debug output if you want.

17:04:18.895 [ERROR] [org.gradle.api.Task] e: [kapt] An exception occurred: java.lang.OutOfMemoryError: Java heap space
at java.awt.image.DataBufferInt.(DataBufferInt.java:75)
at java.awt.image.Raster.createPackedRaster(Raster.java:467)
at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1032)
at java.awt.image.BufferedImage.(BufferedImage.java:333)
at guru.nidi.graphviz.engine.SalamanderRasterizer.doRasterize(SalamanderRasterizer.java:34)
at guru.nidi.graphviz.engine.SvgRasterizer.rasterize(SvgRasterizer.java:37)
at guru.nidi.graphviz.engine.Renderer.toImage(Renderer.java:117)
at guru.nidi.graphviz.engine.Renderer.toOutputStream(Renderer.java:95)
at guru.nidi.graphviz.engine.Renderer.lambda$toOutputStream$5(Renderer.java:90)
at guru.nidi.graphviz.engine.Renderer$$Lambda$8355/802917358.apply(Unknown Source)
at guru.nidi.graphviz.engine.EngineResult.mapIO(EngineResult.java:64)
at guru.nidi.graphviz.engine.Renderer.toOutputStream(Renderer.java:88)
at dev.arunkumar.scabbard.plugin.processor.graphviz.GraphVizBindingGraphProcessor.process(GraphVizBindingGraphProcessor.kt:79)
at dev.arunkumar.scabbard.plugin.ScabbardBindingGraphPlugin.visitGraph(ScabbardBindingGraphPlugin.kt:46)
at dagger.internal.codegen.BindingGraphValidator.isValid(BindingGraphValidator.java:56)
at dagger.internal.codegen.BindingGraphValidator.isValid(BindingGraphValidator.java:49)
at dagger.internal.codegen.ComponentProcessingStep.isValid(ComponentProcessingStep.java:247)
at dagger.internal.codegen.ComponentProcessingStep.processRootComponent(ComponentProcessingStep.java:143)
at dagger.internal.codegen.ComponentProcessingStep.process(ComponentProcessingStep.java:123)
at dagger.internal.codegen.ComponentProcessingStep.process(ComponentProcessingStep.java:51)
at dagger.internal.codegen.TypeCheckingProcessingStep.lambda$process$0(TypeCheckingProcessingStep.java:51)
at dagger.internal.codegen.TypeCheckingProcessingStep$$Lambda$8054/1240509433.accept(Unknown Source)
at com.google.common.collect.RegularImmutableMap.forEach(RegularImmutableMap.java:185)
at dagger.internal.codegen.TypeCheckingProcessingStep.process(TypeCheckingProcessingStep.java:48)
at dagger.internal.codegen.ComponentProcessingStep.process(ComponentProcessingStep.java:116)
at dagger.internal.codegen.ComponentProcessingStep.process(ComponentProcessingStep.java:51)
at dagger.internal.codegen.DaggerStatisticsCollectingProcessingStep.process(DaggerStatisticsCollectingProcessingStep.java:52)
at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:330)
at dagger.shaded.auto.common.BasicAnnotationProcessor.process(BasicAnnotationProcessor.java:181)
at org.jetbrains.kotlin.kapt3.base.incremental.IncrementalProcessor.process(incrementalProcessors.kt)
at org.jetbrains.kotlin.kapt3.base.ProcessorWrapper.process(annotationProcessing.kt:147)
at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)

[arunkumar9t2]

It seems the error happens when png image is generated. Unfortunately scabbard does not have options to configure options for image generation yet. This could possibly be avoided by reducing the dpi of generated image. I will try to provide options in the gradle plugin for next version. In the mean time, may I ask if increasing heap size helps?

One other change I would like to make is to prioritize dot file generation first so that even if png fails there is a dot file which can be manually converted to png via command line.

[gregmcgowan]

Tried setting the heap size at 15GB at still have the same result.

It's a project with 99 gradle modules and ~7000 classes. Dagger is used pretty extensively so I think even if the PNG could be created it would be not really be usable.

Some options to configure the output sounds like good way forward.