Jfoenix: Bad ram usage with scenebuilder

Created on 7 Mar 2016  路  9Comments  路  Source: sshahine/JFoenix

Hi,
I created a simple Pane with a JFXProgressBar as child in it. When i added JFXProgressBar, my ram usage suddenly started to increase rapidly.

jfoenix-ram-usage

So in 1 minute it takes approximately 5 GB ram :), As soon as i remove JFXProgressBar my ram usage stopped and in the next GC call it dropped to 4 GB.

Most helpful comment

Oh wow, I did not expect that. It looks like something is allocating insane amounts of memory outside of the Heap (in native memory) which suggests there is a bug in JavaFX. The memory usage in the graph you have shown is perfectly normal (like expected) but something is rapidly growing outside of the heap (which is where all object allocated inside of java live), which suggests that native JavaFX code is leaking it. The amount of objects allocated inside of Java's heap is 25 MB only.

Now I'm out of direct knowledge and I can only offer things that may or may not help. I'm just guessing what could be the problem.

  • Have you validated that you have the latest version of Java (preferably the one shipped by Oracle)
  • Try to launch SceneBuilder with software rendering only:

sh java -Dprism.order=sw -Dprism.verbose=true -jar "SceneBuilder-8.1.1.jar" 2>&1 | tee scenebuilder.log

Get the executable jar (if you are not already using it) from here.

You might need to re-import the JFoenix jar.

There is no need to make any more heap dumps, since they do not capture the problem. Just report back whether the issue still occurs and attach the scenebuilder.log (maybe verbose prism output yields something useful).

All 9 comments

I forgot to mention my SceneBuilder version, I'm using Gluon SceneBuilder v8.1.1

I tried what you described and was not able to reproduce it:

image

You can see that the heap size does not grow over time for me. Also, it does not even come close to the amount of growth you are describing (5 GB in 1 minute).

The green horizontal line is to demonstrate that the heap does not accumulate ("leaks") memory over time.

That's why I kindly ask you to reproduce the issue on your end.

Getting the latest JFoenix build

Maybe the version of JFoenix you still have is outdated or the one offered for download still contains the issue.

  • Do you have the bleeding edge version of JFoenix? Clone the repo, run ./gradlew jfoenix:jar and pick the jfoenix-0.0.0-SNAPSHOT.jar from subprojects/jfoenix/build/libs/ to import it to SceneBuilder.

    • To replace already imported jars in SceneBuilder, reveal imported jars in the file explorer:

      image

    • Close SceneBuilder

    • Delete the existing JFoenix jar

    • Move the new freshly built jar there

After that, see if you can still reproduce the memory growth.

Collecting a heap dump

If you are still experiencing the growth, do this:

  • Open SceneBuilder, but do not add the JFXProgressBar to the document yet.
  • Open JVisualVM (it's a binary located where java, javac, javaw, etc... are)
  • On the left hand side, select the JVM SceneBuilder is running on. It will probably not be possible to tell right away, so just open them one by one and see if the opened tab on the right mentions something related to SceneBuilder.
  • Now that you are connected to the SceneBuilder JVM, add the JFXProgressBar to the document. Now, wait a moment until you feel like enough memory has been allocated.
  • Take a heap dump. The button for doing so is located on the _Monitor_ tab.
    image
  • A new tab full of information will open. Ignore it for now.
  • Close SceneBuilder for now.
  • On the left hand side, right-click the just collected heap dump and select _Save As..._.
    image
  • Save the resulting file somewhere.
  • Upload the file somewhere. Some tips:

    • The heap dump is uncompressed. I highly recommend zipping it. (for me, I was able to reduce a 50 MB heap dump down to 9 MB)

    • GitHub itself is capable of attaching files up to 10 MB. See the grey bar below the post editor.

    • Just a tip regarding file hosters: pantsu.cat if the zipped file is below 128 MB and something like ge.tt (you need to register) for things below 2 GB.

  • Post the download link in this thread, I will then be able to see what causes the high memory usage (hopefully).

First of all thank you for your guideline :)

I tried to test that in my mac book but i can't reproduce it and there is no extra memory usage But on my PC which runs on Fedora23 i can reproduce it every time. (actually 16 GB ram getting full after 5 or 6 minutes )
In both, i use same SceneBuilder version & latest version of JFoenix .

So here is memory usage of SceneBuilder in my fedora after 1 minute
screenshot from 2016-03-07 21-24-12
And my heap dump too
screenshot from 2016-03-07 21-40-45

heapdump-1457373573126.hprof.zip

Oh wow, I did not expect that. It looks like something is allocating insane amounts of memory outside of the Heap (in native memory) which suggests there is a bug in JavaFX. The memory usage in the graph you have shown is perfectly normal (like expected) but something is rapidly growing outside of the heap (which is where all object allocated inside of java live), which suggests that native JavaFX code is leaking it. The amount of objects allocated inside of Java's heap is 25 MB only.

Now I'm out of direct knowledge and I can only offer things that may or may not help. I'm just guessing what could be the problem.

  • Have you validated that you have the latest version of Java (preferably the one shipped by Oracle)
  • Try to launch SceneBuilder with software rendering only:

sh java -Dprism.order=sw -Dprism.verbose=true -jar "SceneBuilder-8.1.1.jar" 2>&1 | tee scenebuilder.log

Get the executable jar (if you are not already using it) from here.

You might need to re-import the JFoenix jar.

There is no need to make any more heap dumps, since they do not capture the problem. Just report back whether the issue still occurs and attach the scenebuilder.log (maybe verbose prism output yields something useful).

Oh great my problem was solved with your second way, Thank you.
But can you explain what -Dprism.order=sw -Dprism.verbose=true means ?

Here is log message

Prism pipeline init order: sw 
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
(X) Got class = class com.sun.prism.sw.SWPipeline
Initialized prism pipeline: com.sun.prism.sw.SWPipeline
 vsync: true vpipe: false
Mar 07, 2016 10:04:05 PM com.oracle.javafx.scenebuilder.kit.library.user.LibraryFolderWatcher exploreAndUpdateLibrary
INFO: Start exploring JAR /home/saeed/.scenebuilder/Library/jfoenix.jar
Mar 07, 2016 10:04:06 PM com.oracle.javafx.scenebuilder.app.SceneBuilderApp logTimestamp
INFO: JavaFX Scene Builder started

And ram usage
screenshot from 2016-03-07 22-05-39

Basically, -Dprism.order=sw disables hardware acceleration (which runs in native code, that's why I suspected) and renders everything using Java code instead. As a result, you might notice higher CPU usage and lower FPS.

-Dprism.verbose=true enables verbose logging output by the JavaFX renderer. You can leave that out in the future, I figured it might help in case your problem was not solved by enforcing software rendering.

You should probably file Java bug report regarding this issue or search for JavaFX issues regarding Fedora on the internet. This issue is not directly caused by a fault in JFoenix and has to be fixed from the JavaFX side.

Thank you,
Another weird thing, i have two graphic cards on my fedora (nvidia & intel). By default whole system runs on Intel, so i decided to switch to nVidia and run SceneBuilder with that. Then i saw there is no memory issue anymore

I'm having massive memory usages with this as well. My scene builder is locking up. I have updated scene builder and jfoenix. This is while I'm using the standalone application and not the integrated one in IntelliJ. Where am I suppose to enter that code ?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

salwyn picture salwyn  路  3Comments

swftvsn picture swftvsn  路  3Comments

RodrigoSantiago picture RodrigoSantiago  路  3Comments

caoyanfeng picture caoyanfeng  路  3Comments

rfenters95 picture rfenters95  路  4Comments