Open mengjianwei12345 opened 2 years ago
Yes, it is. In InfoflowConfiguration
, call getSolverConfiguration().setDataFlowSolver(DataFlowSolver.GarbageCollecting)
.
Hello, after I use gcsolver, the memory consumption displayed by debugging is more. What is the reason?The first picture is the debugging information without gcsolver, and the second chapter is the debugging information with gcsolver | Taint wrapper hits: 9122613 12:07:07.737 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:853) | Taint wrapper misses: 828399 12:07:07.737 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:872) | IFDS problem with 7414862 forward and 2793052 backward edges solved in 115 seconds, processing 12 results... 12:07:07.737 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:895) | Current memory consumption: 2620 MB 12:07:07.752 | WARN | soot.jimple.infoflow.memory.FlowDroidMemoryWatcher$1.onThresholdReached(FlowDroidMemoryWatcher.java:71) | Running out of memory, solvers terminated 12:07:08.926 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:928) | Memory consumption after cleanup: 605 MB 12:07:08.927 | INFO | soot.jimple.infoflow.data.pathBuilders.BatchPathBuilder.computeTaintPaths(BatchPathBuilder.java:43) | Running path reconstruction batch 1 with 5 elements 12:07:08.927 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:47) | Obtainted 5 connections between sources and sinks 12:07:08.927 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:67) | Memory consumption after cleanup: 605 MB 12:07:08.928 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:68) | Building path 1...
12:13:53.832 | INFO | soot.jimple.infoflow.solver.gcSolver.IFDSSolver.solve(IFDSSolver.java:221) | GC removed abstractions for 1360 methods 12:13:53.832 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:852) | Taint wrapper hits: 4989460 12:13:53.846 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:853) | Taint wrapper misses: 692025 12:13:53.846 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:872) | IFDS problem with 5230383 forward and 1480635 backward edges solved in 142 seconds, processing 12 results... 12:13:53.847 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:895) | Current memory consumption: 2598 MB 12:13:53.853 | WARN | soot.jimple.infoflow.memory.FlowDroidMemoryWatcher$1.onThresholdReached(FlowDroidMemoryWatcher.java:71) | Running out of memory, solvers terminated 12:13:56.496 | INFO | soot.jimple.infoflow.AbstractInfoflow.runTaintAnalysis(AbstractInfoflow.java:928) | Memory consumption after cleanup: 2105 MB 12:13:56.496 | INFO | soot.jimple.infoflow.data.pathBuilders.BatchPathBuilder.computeTaintPaths(BatchPathBuilder.java:43) | Running path reconstruction batch 1 with 5 elements 12:13:56.496 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:47) | Obtainted 5 connections between sources and sinks 12:13:56.496 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:67) | Memory consumption after cleanup: 2105 MB 12:13:56.496 | INFO | soot.jimple.infoflow.data.pathBuilders.ConcurrentAbstractionPathBuilder.computeTaintPaths(ConcurrentAbstractionPathBuilder.java:68) | Building path 1...
The debug info on memory consumption is not precise. In the paper, I used memory snapshots to compute proper memory use.
Background: If you have enough memory in your computer, Java will rather allocate more memory than garbage-collect existing objects, which would take time and reduce performance. Therefore, less pressure on the garbage collector may result in memory usage being compacted less. The main advantage of the GC solver arises when the taint analysis would normally run out of memory. In that case, the GC solver removes objects, and Java gets more chances to reclaim memory, whereas it would otherwise just run out of memory. You can try to simulate this situation using the -Xmx
JVM switch for the maximum heap size, e.g., -Xmx512m
.
Okay, thank you very much
Hello, I would like to ask, is the tool cleanDroid in your paper "Sustainable Solving: Reducing the Memory Footprint of IFDS-Based Data Flow Analyses Using Intelligent Garbage Collection" already integrated in FlowDroid? If so, which module is it in?