memory leak?

[schoeberl]

I ran a single-threaded simulation with Verilator and ran out of heap (1 GB) after around 30000 simulation cycles. When analyzing a heap dump, I get the following:

One instance of chiseltest.internal.ThreadedBackend$Timescope loaded by sbt.internal.LayeredClassLoader @ 0x7c35308d8 occupies 982.919.064 (92,04 %) bytes. The memory is accumulated in one instance of scala.collection.mutable.HashEntry[], loaded by sbt.internal.ScalaLibraryClassLoader @ 0x7c00000b0, which occupies 982.918.832 (92,04 %) bytes.

I am not using any hash map in my simulation, so this is probably internal to ChiselTest.

[ekiwi]

Thanks for reporting this with all the details. Do you have a link to your testbench?

[schoeberl]

I’ve committed the version with the issue in: https://github.com/t-crest/soc-comm Run it with: sbt "testOnly s4noc.PerformanceTest" Thanks for looking into it. Cheers, Martin

…

On 26 Sep, 2022, at 15:25, Kevin Laeufer ***@***.***> wrote: Thanks for reporting this with all the details. Do you have a link to your testbench? — Reply to this email directly, view it on GitHub <#557 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAE63GC6ILXTZE2UR6YBM43WAGP6HANCNFSM6AAAAAAQVXBV4E>. You are receiving this because you authored the thread.

[ekiwi]

This won't fix the actual bug, but since it seems like you are not using any fork or timescope constructs, could you try adding the following annotation: chiseltest.internal.NoThreadingAnnotation
That might speed up your test significantly.

[schoeberl]

Thanks, yes, that gave a speedup of almost 2. Some time is spent on compiling the Verilator simulation.

BTW, would be nice if this is default and only on a fork the tester switches to the multithreaded version.

Cheers,
Martin

[ekiwi]

BTW, would be nice if this is default and only on a fork the tester switches to the multithreaded version.

Transparently doing that is hard since it would require re-architecting the whole threading infrastructure. Currently if you use threads, a new thread is spawned immediately which makes things simpler by keeping all test threads the same. If you want to change this, one would have to special case the first thread to run on the main thread and spawn a separate scheduler thread for synchronization (currently the scheduler runs on the main thread). That is quite a bit of work and no one has shown enough interest to do this.