Aggressive cache clearing in CFR?

[bluelhf]

I'm using FabricMC's CFR fork under Enigma to decompile a relatively large JAR (46MiB), but I'm running into issues with memory usage because of CFR's caching: Is there any way to clear those caches in CFR? _{P.S. I understand that this issue tracker is less relevant for forks, but FabricMC's CFR} ^{is quite up-to-date and doesn't have any meaningful changes (change comparison)}

[leibnitz27]

Have you tried --lomem true ?

On Mon, 21 Jun 2021, 18:42 Ilari Suhonen, @.***> wrote:

I'm using FabricMC's CFR fork https://github.com/FabricMC/cfr under Enigma https://github.com/FabricMC/Enigma to decompile a relatively large JAR (46MiB), but I'm running into issues with memory usage because of CFR's caching: [image: hprof memory snapshot] https://user-images.githubusercontent.com/52505120/122803869-dc3d4c00-d2cf-11eb-84de-f0158d62d21f.png Is there any way to clear those caches in CFR? P.S. I understand that this issue tracker is less relevant for forks, but FabricMC's CFR is quite up-to-date and doesn't have any meaningful changes (change comparison https://github.com/FabricMC/cfr/compare/master...leibnitz27:master)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/leibnitz27/cfr/issues/256, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXCEHSCD5ARDXIDVDL35TTT52ZZANCNFSM47CA7CJA .

[bluelhf]

@leibnitz27 What does --lomem true do in CFR? Enigma's environment means I can't explicitly specify the commandline settings, I'd have to set them programmatically.

[bluelhf]

I figured it out - I'm using reflection and my own subclass of net.fabricmc:cfr:0.0.3's CfrDecompiler to pass lomem to CFR, and also manually clearing the overload method set cache every now and then.

[Col-E]

I'm using reflection and my own subclass of net.fabricmc:cfr:0.0.3's CfrDecompiler to pass lomem to CFR

What. You can pass a Map<String, String> of options to the CFR driver. You should be able to do map.put("lomem", "true");

CfrDriver driver = new CfrDriver.Builder()
                .withClassFileSource(source)
                .withOutputSink(sink)
                .withOptions(map_goes_here) // here
                .build();

[bluelhf]

I'm using reflection and my own subclass of net.fabricmc:cfr:0.0.3's CfrDecompiler to pass lomem to CFR

What. You can pass a Map<String, String> of options to the CFR driver. You should be able to do map.put("lomem", "true");

CfrDriver driver = new CfrDriver.Builder()
              .withClassFileSource(source)
              .withOutputSink(sink)
              .withOptions(map_goes_here) // here
              .build();

The key here is Enigma, the environment is different - while it uses CFR it has a separate driver class

[Col-E]

The key here is Enigma

Oh.... well that's a very unfortunate implementation.

That being said, I see why they're doing that to get the DCCommonState. See: CfrDriverImpl.java#L62

@leibnitz27 The TODO is from Nov 9, 2018, and the cfr_tests repo first commit is from 2019. Has there been any change in structure or test logic that would allow the state to be stored or accessible in any way from the driver?