gc options for best JFX performance

[Richard Bair]

I would be interested in seeing how much time is being spent in GC. Sometimes the best thing is to have a small heap size -- maybe you ought to try to set it to 32M or something (not sure how small you can make it and still fit all your images etc in the heap). Large heaps lead to longer pauses (of course my data may be out of date).

Also are you running on Mac or Windows? ON Mac we've got some synchronization issues which I think were just very recently fixed, so you would get jerky animations, whereas on Windows it should be pretty smooth.

Richard

On Jun 2, 2012, at 9:16 AM, goddard at seznam.cz wrote:

> Hi Jose,
> 
> you don't have to build the Timeline animation objects dynamically, e. g. use "new KeyFrame" or "new KeyValue" each time you trigger firing. You can create them earlier, before you enter the event handler.
> In addition, I think that the animation API is highly optimized so it doesn't create too many objects etc.
> Take a heap dump, java core and analyze it. Or you can use the application profiler (VisualVM) in Netbeans.
> Unless you know exactly what's going on, it's hard to make the right decision and move forward.
> 
> Regards, Jiri
> 
> ------------ Původní zpráva ------------
> Od: Jose Martinez <jmartine_1026 at yahoo.com>
> Předmět: Re: gc options for best JFX performance
> Datum: 02.6.2012 16:21:52
> ----------------------------------------
> Thanks Jiri.  Yeah I understand those things.  I was naively hoping that there
> was some magic concoction of JVM options that works ideally for JFX apps.
> 
> I try very hard not to create new objects during game play but because the
> KeyFrame and KeyValue classes  immutable I imagine that those are what are
> building up in memory and getting cleaned up by the GC.  I create all my
> projectiles and enemy units before the round begins.  But with each shot fired I
> have to create KeyFrames and KeyValues to send the projectile to its
> destination.  Maybe making those classes non-immutable will help in keeping
> memory down.  I imagine there might be some complexity to changing a Keyframe
> that is attached to a Timeline, or a KayValue that is attached to a KeyFrame,
> which is probably why they were designed to be immutable.
> 
> Also I have to create new Duration objects to keep track of time.
> 
> thanks
> jose
> 
> 
> ________________________________
> From: "goddard at seznam.cz" <goddard at seznam.cz>
> To: Jose Martinez <jmartine_1026 at yahoo.com>
> Cc: openjfx mailing list <openjfx-dev at openjdk.java.net>
> Sent: Saturday, June 2, 2012 4:52 AM
> Subject: Re: gc options for best JFX performance
> 
> Hi,
> 
> I believe there're no generic JVM settings for "best performance" Until you have
> perf. issues, I'd live with the default.
> If you want to do perf. tuning, it's application / environment dependent.
> Identify your bottleneck (network, i/o, memory, code etc.) and then try specific
> settings for that one.
> If you have big GC pauses, think about how much memory your app uses and if the
> heap is not too large, or what's the lifetime of objects in your app and adjust
> the generations in the heap accordingly.
> 
> Regards, Jiri
> 
> ------------ Původní zpráva ------------
> Od: Jose Martinez <jmartine_1026 at yahoo.com>
> Předmět: gc options for best JFX performance
> Datum: 02.6.2012 07:36:54
> ----------------------------------------
> Hello,
> 
> I have tried the following GC modes but none of them get rid of the noticeable
> 'stop the world' delays.
> 
> -XX:+UseParallelGC 
> 
> -XX:-UseParallelOldGC
> 
> -XX:-UseParNewGC 
> 
> -XX:+UseConcMarkSweepGC
> 
> 
> Out of those my favorite so far is UseParNewGC.
> 
> I also use the following options.
> --Xms150m -Xmx200m  -XX:MaxGCPauseMillis=1  
> 
>  
> Are there other options that you would recommend?  Has anyone come up with a
> concoction of options that works best or a rule of thumb for configuring GC in
> JFX applications?
> 
> If I cannot find a good set of options I will have to resort to calling
> System.gc() at strategic intervals.
>  
> thanks
> jose
> 
>