Possible memory leakage in v1.0.0 (related with neureka.devices.CustomDeviceCleaner )

[sunjianxy301]

I have started using neureka 1.0.0 in my java project recently. Thank you very much for sharing this great project. I in desperate need of your help with solving a possible memory leakage. OutOfMemoryError will be raised as neureka functions calls grows. The following message from eclipse might help:

One instance of neureka.devices.CustomDeviceCleaner loaded by sun.misc.Launcher$AppClassLoader @ 0x3c0013e70 occupies 16,455,983,640 (99.20%) bytes. The memory is accumulated in one instance of java.lang.Object[], loaded by , which occupies 16,455,983,584 (99.20%) bytes.
Thread java.lang.Thread @ 0x430d0b2e0 Thread-10 has a local variable or reference to neureka.devices.CustomDeviceCleaner @ 0x3e03d0818 which is on the shortest path to java.lang.Object[6153400] @ 0x6e4ee2580. The thread java.lang.Thread @ 0x430d0b2e0 Thread-10 keeps local variables with total size 424 (0.00%) bytes.
Significant stack frames and local variables
neureka.devices.CustomDeviceCleaner.run()V (CustomDeviceCleaner.java:52)
neureka.devices.CustomDeviceCleaner @ 0x3e03d0818 retains 16,455,983,640 (99.20%) bytes
The stacktrace of this Thread is available. See stacktrace. See stacktrace with involved local variables.

My program was running on JDK 8 (Intel CPU, Windows 11 x64) .

[sunjianxy301]

Maybe I should call MutableTensor.delete() for each Tensor. My problem should be solved.

[sunjianxy301]

I've just found calling delete() on Tensor Object does not solve the problem. There are still a huge number of neureka.devices.ReferenceCounter, CustomDeviceCleaner$ReferenceWithCleaup object in my heap after i tried to call delete() on each Tensor used in the computing.

[sunjianxy301]

It seemed to me that the field 'list' of CustomDeviceCleaner has never been cleared and it could just keep growing.

final class CustomDeviceCleaner implements DeviceCleaner, Runnable
{
    private final ReferenceQueue<Object> _referenceQueue = new ReferenceQueue<>();
    private final long _timeout = 60 * 1000;
    private int _registered = 0;

    List<Object> list = new ArrayList<>();

    static class ReferenceWithCleanup<T> extends PhantomReference<T>
    {
        private final Runnable _action;

        ReferenceWithCleanup(T o, Runnable action, ReferenceQueue<T> queue) {
            super( o, queue );
            _action = action;
        }
        public void cleanup() {
            _action.run();
        }
    }

    @Override
    public void register(Object o, Runnable action) {
        synchronized ( _referenceQueue ) {
            list.add(new ReferenceWithCleanup<Object>(o, action, _referenceQueue));
            _registered++;
            if ( _registered == 1 ) new Thread( this::run ).start();
        }
    }
...
}

[create-issue-branch]

Branch issue-26-Possible_memory_leakage_in_v1_0_0_related_with_neureka_devices_CustomDeviceCleaner created!

[Gleethos]

Thank you so much for finding and reporting this issue!
I will push a fix soon.

[sunjianxy301]

Great! Thank you for responding so quickly

[Gleethos]

I merged a hand full of general improvements from another branch which
already includes a rewrite of the device cleaner.
Based on my testing this should not produce any memory leaks.
A similar design is used in other projects as well. So it should be ok.

But can you verify this using the latest commit hash from main and verify in your code as well?
If you are using Gradle, you can check out the snapshot like this:

allprojects {
	repositories {
		//...
		maven { url 'https://jitpack.io' }
	}
}
// ...
dependencies {
	implementation 'com.github.Gleethos:neureka:241a79873c1c1da817a792282168af3914be9d6c' //main hash
}

I want to make sure that this is really fixed before I make a full release.
So it would be of great great help if you could approve the changes.

[sunjianxy301]

I will try it. Thank you.

…

On Tue, Dec 10, 2024 at 10:07 AM Daniel Nepp ***@***.***> wrote: I merged a hand full of general improvements from another branch which already includes a rewrite of the device cleaner. Based on my testing this should not produce any memory leaks. A similar design is used in other projects as well. So it should be ok. But can you verify this using the latest commit hash from main and verify in your code as well? If you are using Gradle, you can check out the snapshot like this: allprojects { repositories { //... maven { url 'https://jitpack.io' } } } // ... dependencies { implementation 'com.github.Gleethos:neureka:241a79873c1c1da817a792282168af3914be9d6c' //main hash } I want to make sure that this is really fixed before I make a full release. So it would be of great great help if you could approve the changes. — Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADDQNAHHJLA2CZGG6YGODG32E3YQ7AVCNFSM6AAAAABS52GHZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZRG4ZTINZTGE> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>

[sunjianxy301]

Confirmed. No memory leakage. FYI, I have to use it like this:

    <dependency>
        <groupId>com.github.Gleethos</groupId>
        <artifactId>neureka</artifactId>
        <version>241a79873c1c1da817a792282168af3914be9d6c</version>
        <exclusions>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.jetbrains.kotlin</groupId>
                <artifactId>kotlin-stdlib-jdk7</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.jetbrains.kotlin</groupId>
                <artifactId>kotlin-stdlib-jdk8</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

I am using JAVA 8, I wonder if the coming release will not depend on kotlin stdl libs and a snapshot version slf4j-api. Anyway, thank you. Great project!

[Gleethos]

Currently I have the following dependencies configured:

    implementation group: 'com.google.errorprone', name: 'error_prone_annotations', version: '2.27.0'
    implementation group: 'org.jspecify', name: 'jspecify', version: '1.0.0'
    implementation 'org.jocl:jocl:2.0.5'
    implementation group: 'org.slf4j', name: 'slf4j-api', version: '[1+, )'

This is different from before in that now the slf4j requirement is now more lenient,
and there are two small annotation libraries for static analysis...

Kotlin is only used in the test suite.

I hope that is compatible with your usage sites!

[Gleethos]

You have to exclude kotlin-stdlib for it to work?
That should not be necessary. This dependency should not be part of neureka.

[sunjianxy301]

You have to exclude kotlin-stdlib for it to work? That should not be necessary. This dependency should not be part of neureka.

I saw kotlin-stdlib in the result of IntellijIdea's Analyze Dependencies function. It is not a big deal. I can remove it.

[Gleethos]

I dispatched the release as version 1.0.1. Thank you again for the bug report and also
thank you for using Neureka, I hope it continues to provide value for you and
the projects you use it in.

I am using JAVA 8

Oh and just for your information, Neureka is also fully upwards compatible, so
if you are not using it in a legacy project stuck on Java 8, feel free
to use newer Java versions like 21.