How to improve Java app efficiencies?

vikana · Sep 20, 2007

FuturesScalper: thank you for all the good information.

I've found the that JVM performance on 64 bit dual core systems can be improved quite a bit by tweaking the garbage collection algorithms (there are now several).

Good link:
http://www.onjava.com/pub/a/onjava/2006/11/01/scaling-enterprise-java-on-64-bit-multi-core.html

speculatus · Sep 21, 2007

Quote from vikana:

FuturesScalper: thank you for all the good information.

I've found the that JVM performance on 64 bit dual core systems can be improved quite a bit by tweaking the garbage collection algorithms (there are now several).

Good link:
http://www.onjava.com/pub/a/onjava/2006/11/01/scaling-enterprise-java-on-64-bit-multi-core.html

Guys, come on, just admit it - for real-time equities/options trading systems noting can beat C++. Use Java or Python is great for pilot systems, then code working system in C++.

You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.

speculatus · Sep 21, 2007

Quote from vikana:

FuturesScalper: thank you for all the good information.

I've found the that JVM performance on 64 bit dual core systems can be improved quite a bit by tweaking the garbage collection algorithms (there are now several).

Good link:
http://www.onjava.com/pub/a/onjava/2006/11/01/scaling-enterprise-java-on-64-bit-multi-core.html

Guys, come on, just admit it - for real-time equities/options trading systems nothing can beat C++. Use Java or Python is great for pilot systems, then code working system in C++.

You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.

FutureScalper · Sep 21, 2007

Guys, come on, just admit it - for real-time equities/options trading systems nothing can beat C++. Use Java or Python is great for pilot systems, then code working system in C++.

You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain. [/QUOTE]

We all know about "religious language wars". I'm not gonna fall for this one... Java GC does NOT take SECONDS. Maybe in the hundred millisecond range infrequently s is more like it, depending how you configure the runtime.

The term "realtime" is a relative thing anyway...

Oops, I promised not to say anything in our defense.

'Nuff said.

speculatus · Sep 21, 2007

Quote from FutureScalper:

Guys, come on, just admit it - for real-time equities/options trading systems nothing can beat C++. Use Java or Python is great for pilot systems, then code working system in C++.

You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.

We all know about "religious language wars". I'm not gonna fall for this one... Java GC does NOT take SECONDS. Maybe in the hundred millisecond range infrequently s is more like it, depending how you configure the runtime.

The term "realtime" is a relative thing anyway...

Oops, I promised not to say anything in our defense. 'Nuff said. [/QUOTE]

Full GC cycle takes seconds even with the fine-tuned GC parameters in an application with a good load (of course, we are talking about soft real-time trading systems here).

FutureScalper · Sep 21, 2007

Full GC cycle takes seconds even with the fine-tuned GC parameters in an application with a good load (of course, we are talking about soft real-time trading systems here).

Well, yes, this is "soft" realtime trading. Using an operating like Windows XP Pro is a "soft" realtime OS anyway, and "internet" network delays are nothing like hard pipes to exchanges, and so on...

The meaning of "real time" is often simply "plenty fast enough".

Using IB's TWS on standard DSL, for example, I bump a live Globex-based order in 120 msecs round-trip. And I analyze somewhere up to around 10,000 messages per minute from TWS market depth, etc. For some, that's child's play; for others' it's ridiculous overkill... it depends.

This is only "soft" real time trading, of course, but it's all on a continuum of what's "fast enough" to do the job. Systems are only as fast as the slowest link in the chain anyway.

You're right, of course.

originalskunk · Sep 21, 2007

Quote from speculatus:

Full GC cycle takes seconds even with the fine-tuned GC parameters in an application with a good load (of course, we are talking about soft real-time trading systems here).

If you have a decent machine, this flag will solve all your problems

-XX:+UseConcMarkSweepGC

kiwi_trader · Sep 23, 2007

Quote from FutureScalper:

EXTREME PERFORMANCE

Ran across some extreme performance flags for the "server vm" in case you want to go to the trouble of installing it. Basically the "client vm" is delivered with the jre. To get the server vm more comprehensive optimizations, you have to install the jdk, and then get the jvm.dll under the "server" folder, and make a server folder under your jre installation parallel to the client folder which already exists.

Then you can say "java -server..." How much of this works with the client vm, I do not know. For extreme performance you really need the "server vm", as I stated above.

Check these little-known options which over-ride the Hotspot compilers heuristics and enable it to consider and inline much larger Java methods down to machine code:

(taken from a snippet of jnlp)
j2se version="1.6.0+" java-vm-args=" -server -dsa -XX:+ForceTimeHighResolution -XX:ThreadStackSize=192 -XX:CompileThreshold=5 -XX:+AggressiveOpts -XX:CICompilerCount=1 -XX:+UseBiasedLocking

-XX:+RelaxAccessControlCheck

-XX:MaxInlineSize=8192 -XX:-DontCompileHugeMethods

-XX:+UseFastAccessorMethods -Xbatch -Xss192k -Xms240m -Xmx240m -Xnoclassgc

...
MaxInlineSize can increase the size of a method the compiler will "inline", and by disabling the DontCompileHugeMethods, you enable it to compile much larger methods (ignored by default) into machine code as well as possibly inlining them for execution.

I've tried this, on my custom trading platform which uses a lot of Swing and crazy processing, and it SCREAMS.

You may have to adjust some stack sizes, etc., but apparently, this stuff is magic for HIGH performance when you really NEED it.

FutureScalper

The suggestion to use server VM instead of client VM makes a huge difference to potential performance. I'm not sure why we use the -client VM for anything where performance matters.

http://docs.sun.com/app/docs/doc/819-3681/abeib?a=view

kiwi_trader · Sep 23, 2007

Quote from originalskunk:

If you have a decent machine, this flag will solve all your problems

-XX:+UseConcMarkSweepGC

If your machine has only one or two processors then you should use these two together:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode

ref: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#icms

FWIW my current line for Sun Java is:

Code:

j2se version="1.6+" java-vm-args=" -Dsun.java2d.noddraw=false -server -Xss128k
 -Xms256m -Xmx256m -XX:NewRatio=3 -XX:+ForceTimeHighResolution -XX:CompileThreshold=50 
-XX:ThreadStackSize=192 -XX:+AggressiveOpts -XX:+UseFastAccessorMethods 
-XX:+RelaxAccessControlCheck -XX:MaxInlineSize=8192 -XX:-DontCompileHugeMethods 
-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+DisableExplicitGC -Xnoclassgc"

For jrockit-R27.3.1-jre1.6.0_01 the corresponding optimization is:

Code:

 -Dsun.java2d.noddraw=false -server -Xms256m -Xmx256m -Xns64m -XXaggressive:opt
-Xgcprio: pausetime -XpauseTarget=250ms -XXcallprofiling

squeeze · Sep 23, 2007

Quote from speculatus:

Guys, come on, just admit it - for real-time equities/options trading systems noting can beat C++. Use Java or Python is great for pilot systems, then code working system in C++.

You beloved Java garbage collector will kill you with garbage collector cycles lasting seconds when load is high... You have to pay for every luxury Java gives you. Java is a good language, but just not for this domain.

I am not sure why Java is so slow as C# is also managed and seems to be on average, just as fast as C++ in all the benchmarking I have done.

I have run tests on the C# garbage tester and found it does not get in the way of real-time performance at all. Process scheduling latency under Windows is the biggest source of problems for C# soft real-time systems.