Memory leak

[Marko19907]

There's a memory leak somewhere, the RAM usage climbs to about 1.6 GB after around 40 minutes and all the connected devices get lost.

[Valkryst]

It's likely an issue with something in JInput, as I was just reading a similar issue yesterday. I'll poke around the source and see if there's anything solvable with reflection 🤔

[Valkryst]

As far as I could tell, the issue seems to be that this class was spawning a new thread every time HotSwapPoller#getControllers re-initialized the DefaultControllerEnvironment.

If you switch your version to 74eaae30ec931807ee39ba7f854403cfad65a6df, the issue should be resolved.

Though I can't currently test the library on OSX/Linux, I didn't see any obvious issues in their code

[Marko19907]

Thanks! Unfortunately, that breaks the HotSwapExample at least. It seems like it's stuck in thread.join(); here 🤔

[Valkryst]

Documenting a few attempted solutions from today

QueueThread with Thread.interrupt()

The straightforward way of eliminating all of the "dead" threads seemed to be something like this:

final String[] JINPUT_THREADS_TO_KILL = {
    "net.java.games.input.RawInputEventQueue$QueueThread"
};

for (final var thread : Thread.getAllStackTraces().keySet()) {
    if (Arrays.asList(JINPUT_THREADS_TO_KILL).contains(thread.getClass().getName())) {
        thread.interrupt();
        thread.join();
        break;
    }
}

You would think that this would work, and maybe it does under certain configurations as litiengine also uses the same technique. However, the thread gets stuck on a poll call and the isInterrupted check is never run.

I also attempted to call DummyWindow.destroy on the QueueThread#window variable, thinking it might cause poll to throw an exception and allow the isInterrupted check to work. This causes an exception to be thrown from the native function. I believe the error was due to calling DestroyWindow from outside of the thread that created the window (e.g. QueueThread).

Note: Need to double-check that last solution. Maybe I can catch the error and continue to join the thread? I forget whether it was crashing the whole program or just causing an exception in the code.

QueueThread with Forced Exception

Attempted the following:

1. Setting the QueueThread#exception variable. There is a check which causes it's run function to quit if exception is set.
2. Setting the QueueThread#window variable to null. This should have caused an exception when accessing it.
3. Setting the QueueThread#monitor variable to null. This should have caused an exception when accessing it.

None of these solutions had an affect as QueueThread was stuck on the poll call and never ran code which would cause the thread to hit an exception.

QueueThread with Thread.stop()

Against all advice, I attempted to use the deprecated Thread.stop() function to forcefully terminate the "dead" threads. This had no affect.

Manually Update QueueThread#devices

As you can see on the hotswap-fix-attempt-2 branch, I tried copying some of the code from RawInputEventQueue (it's a mess of reflection and a bit tough to read). The intent was to retrieve an updated list of connected devices, without deleting and re-creating the DefaultControllerEnvironment, and then access the existing QueueThread instance and update it's devices instance variable.

For some reason, I havent had a chance to look into it yet, the returned devices are always the same. Though unplugging my controller caused some sort of reflection exception.

[sunsigne]

it looks like thread.join(); is causing some issues, while thread.interrupt() alone seems enough to do the trick... I don't really have time to push deep tests but I'm exhibitor in a video game event mi-november, all a saturday long ! It will be the perfect occasion to see if it's all ok
(EDIT : my bad, didn't checked correctly, it does NOT do the trick D: !)

[sunsigne]

I mean, it just seems to work fine, writting this :

[Valkryst]

Which operating system are you testing on @sunsigne?

I believe each native implementation works a little differently, and the one that Windows 11 defaults to is the one with an issue. When I test that approach, you can see a new thread being created on every call:

[Marko19907]

I mean, it just seems to work fine, writting this :

I've tried this myself but no luck, still creates a new thread and doesn't kill off the old ones

[sunsigne]

Which operating system are you testing on @sunsigne?

I believe each native implementation works a little differently, and the one that Windows 11 defaults to is the one with an issue. When I test that approach, you can see a new thread being created on every call:

Ho dang ! You're right ! It was all an illusion, it still create some threads ... my bad, didn't checked correctly (I'm on windows 10 btw)

[Valkryst]

Checking JInput's source it looks like almost every Windows version uses DirectAndRawInputEnvironmentPlugin, which in-turn uses the QueueThread that we're trying to work around. I also checked litiengine's PRs to see if anyone has complained about their implementation, but I didn't see anything at a glance.

I'll DM their devs, if I can, and ask if they did anything more to bypass the issue 🤔

[sunsigne]

It looks like it's even a bigger problem than I thought ... Any gamepad input CREATE a new thread, even without ours hacking-patches : you clicked 100 times ? You created 100 thread and they all are living in the same time ... (i might be wrong, but my console is pretty clear on how many of them was created) :

EDIT : i might be dumb, if for (final var thread : Thread.getAllStackTraces().keySet()) informs you about all thread created, even dead ones, so it's ok

[Valkryst]

Gave that a shot with the ControllerExample from the README, but I can't reproduce that issue:

Just saw your edit, that makes sense 👍

[Valkryst]

One possible solution, and this should be a last resort due to how wasteful it is, would be to refactor this library into a client-server architecture where:

• The client would listen for events on a local port.
• The server would listen for events from JInput and publish them to a local port.
• The client would start the server on a separate JVM (possibly using ProcessBuilder) and allow the memory leak to happen for some set period of time (a few minutes?) before being shut down and restarted.
  • When the JVM shuts down, it would free up any leaked resources.

Another would be to look into why this PR was never merged into JInput, as it adds hot swap functionality 👀