This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
There's a possible Memory Leak when using JSONList (@Property with array=true). Here's a github project that demonstrates the problem: https://github.com/cliveli/dukescriptArray Java memory is released when using jdk8_u92, but process memory is growing. Objects released after clearing the JSONList seem to stay there forever (or until the app crashes).
I have tested the application with 1.8.0_101 --- dukescriptArray/client$ mvn -X exec:exec Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T13:57:37+02:00) Maven home: /home/devel/bin/apache-maven-3.3.3 Java version: 1.8.0_101, vendor: Oracle Corporation Java home: /usr/lib/jvm/java-8-oracle/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.19.0-49-generic", arch: "amd64", family: "unix" --- and I can confirm that jvisualvm shows no leaks in Java memory heap anymore. Yet the process memory is going up.
Correction, after observing the application in JDK1.8.0_101 for two minutes it seems the number of JSObjects and Knockout instances is growing: com.sun.webkit.dom.JSObject 4495872 +4,495,872 +187,328 org.netbeans.html.ko4j.Knockout 549264 +549,264 +11,443 Ten randomly selected Knockout instances were marked as "GC Root" - e.g. being held by the WebView native code. I have no reason to doubt that most of 11443 instances is held by the WebView too.
Created attachment 161625 [details] Here is the patch the I am using for logging
With the above patch it is easy to see that the biggest problem is in https://github.com/cliveli/dukescriptArray/blob/master/client/src/main/java/world/hello/DataModel.java#L187 which allocates the MIFSFPTrunkVM model in a completely wrong BrwsrCtx which somehow leads to enormous allocations of the JavaScript objects. After following changes to the project, the problem is way smaller: dukescriptArray/client$ git diff diff --git a/client/pom.xml b/client/pom.xml index 1b5a3b5..ad86bbe 100644 --- a/client/pom.xml +++ b/client/pom.xml @@ -83,8 +83,6 @@ <arguments> <argument>-classpath</argument> <classpath/> - <argument>-javaagent:${project.build.directory}/springloaded.jar</argument> - <argument>-noverify</argument> <argument>-Dbrowser.rootdir=${basedir}/src/main/webapp/</argument> <argument>-Dnetbeans.inspect.port=${netbeans.inspect.port}</argument> <argument>${exec.debug.arg}</argument> diff --git a/client/src/main/java/world/hello/DataModel.java b/client/src/main/java/world/hello/DataModel.java index 48cf21f..2e765ff 100644 --- a/client/src/main/java/world/hello/DataModel.java +++ b/client/src/main/java/world/hello/DataModel.java @@ -35,6 +33,7 @@ final class DataModel { } private static Data ui; + private static MIFSFPTrunkVM mifsfpTrunkPrototype; private static BrwsrCtx ctx; @@ -49,6 +48,7 @@ final class DataModel { static void onPageLoad() throws Exception { ui = new Data(); Models.toRaw(ui); + mifsfpTrunkPrototype = new MIFSFPTrunkVM(); Router.registerBinding(); // ui.applyBindings(); Models.applyBindings(ui, "control"); @@ -184,7 +184,7 @@ final class DataModel { } newlist.clear(); for (int i = 0; i < 100; ++i) { - newlist.add(new MIFSFPTrunkVM()); + newlist.add(mifsfpTrunkPrototype.clone()); } ctx.execute(new Runnable() { I still see too many Knockout instances being GC root. I'll see what I can do with it.
I've just did measurements on the JDK1.8.0_112 build and yes, it seems that Java memory leaks are gone. Looks like the critical fixes has been ported back to JDK8.
I've reported the "native memory leak" problem as https://bugs.openjdk.java.net/browse/JDK-8164792 Marking this bug as invalid as this seems to be the JDK problem. Let's track the progress on the JDK issue.