Prevent memory leaks by cleaning up playlist listeners#218
Conversation
Borewit
changed the title
7903e94 to
6d75ad7
Compare
|
👉🏻 Should I be testing this build? Additional information pertaining to the memory usage of this particular build:
|
|
About the aforesaid post: I cannot remember that the excessive CPU-usage was ever an issue before — even on the ancient PC. The available CPU-processing power and physical memory coped rather well with the job at hand. Can you think of anything that could've changed that state of affairs? More importantly, do you think it can be fixed, or improved upon? |
Yes that is useful, if it does not break anything it good to go.
That has been introduced in #203, when we enabled parallel processing. It uses nearly uses all CPU power available to get the job done, which should not be an issue. |
2 participants
Ths PR improves the de-registration of playlist listeners, to prevent memory leaks.
Although at various places the life-cycle management of playlist listeners improves, as well duplicate playlists lists has been removed, playlists are still being present in memory after closure of the playlist. It looks like at least a Future of the SwingWorker, which loads the playlist in the background keeps a reference to the playlist, preventing the garbage collector from cleaning it. I could not find a method to clear the Future or the SwingWorker. As the number of SwingWorker are limited as they are rotated from a pool, I assume the leak is limited.
May have resolved #219