Jikoo
Cancel deletion for unloaded worlds
This plugin works in conjunction with a hot loaded independent world plugin similar to MythicDungeon It will delete the corresponding cache because it did not listen to the world uninstallation event This leads to Concurrent HashMap<String, RegionInfo>regions and HashMap<String, WorldInfo>infinite storage of world instances This leads to memory overflow I hope it can be repaired
Huh. You know, I never really even considered worlds being unloaded, and late-loaded worlds were more added because certain world providers (looking at you, Iris) just don't bother loading worlds until after the postworld phase of startup. Supporting worlds that were only online for a small portion of the time was never really my intention. You probably should be using your own deletion implementation if you want those transient worlds to have reliable deletion passes made over them. It also seems really weird that the world is holding onto chunks. Why didn't those get flushed when it got unloaded?
Either way, yeah, this is bad on Regionerator's side.
I've pushed ~~53891d9bf05222204918d4e3ddd47f3bbaeb7c72~~, which should resolve the worst of the issues. It still needs some work: runnables should be cancelled directly when the world is unloaded rather than during periodic checks, and I'm not sure whether the world is removed from the server's world list before or after the event is called. I assumed before, but you know what they say about assuming.
/e: Most importantly, runnables that have finished running will no longer hold a world reference. Perhaps I should also make cancellation clear the world reference, that would potentially allow it to be eligible for gc a little earlier.
/e2: That is now done in ~~4f48b78605d117e872584a15227fa6ba291679d2~~. The leak is still partially present, but at least worlds should be released as soon as the next deletion start check runs. Those happen once per minute.
/e3: I in fact actually made a very silly logical error and have squashed them all and pushed 47252b43de5f7728b8af3c5271230bc7e58c07a1 so as to not have an "oops" commit message in the main history. This is why we work on branches, and other lessons I will learn but disregard in semi-emergencies.