Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

memory leak? #557

Open
schoeberl opened this issue Sep 26, 2022 · 5 comments
Open

memory leak? #557

schoeberl opened this issue Sep 26, 2022 · 5 comments

Comments

@schoeberl
Copy link
Member

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
Copy link
Collaborator

ekiwi commented Sep 26, 2022

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

@schoeberl
Copy link
Member Author

schoeberl commented Sep 27, 2022 via email

@ekiwi
Copy link
Collaborator

ekiwi commented Sep 27, 2022

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
Copy link
Member Author

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
Copy link
Collaborator

ekiwi commented Sep 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants