Peter LawreyCEO of Higher Frequency TradingJAX Finance 2015

Determinism in Finance

Peter Lawrey

Java Developer/Consultant for hedge fund and trading firms for 6 years.Most answers for Java and JVM on stackoverflow.comFounder of the Performance Java User’s Group.Architect of Chronicle Software

Agenda

Lambda functions and state machinesRecord every inputDeterminism by DesignRecord every outputJava 8 and GarbageChronicle Queue demo

Lambda Functions

No mutable stateEasy to reason aboutEasy to componentizeBut … no mutable state.

State Machine

Local mutable state

Easier to reason about, than shared state

Easier to componentize

Not as simple as Lambda Functions

Lambda functions and a state machine

Record every input

By recording every input you can recreate the state of the system at any point and recreate bugs, test rare conditions, and test the latency distribution of your system.

But

This approach doesn’t support software upgrades.

A replay facility which is implemented after the fact might not recreate your system completely.

Determinism by design

You want a system where producers write every event, and consumers and continuously in replay. This way you can be sure that you have this facility early in the development cycle and you know that you have recorded every event/input.

This facility can help you in the testing of your system by allowing to you build small simple tests to huge complex data driven tests.

Record every output

Supports live software upgrades. By recording and replaying outcome you can have a system which commits to any decision the previous one made. Ie you can change the software to make different decisions.

This can be tested at the API level by having two state machines, where the input of one is the output of the other.

Isn’t writing to disk slow?

Uncommitted synchronous writes can be extremely fast. Typically around a micro-second. The writes are synchronous to the application so data is not lost if the application dies, but not actually committed to disk.

To prevent loss of data on power failure, you can use replication.

Doesn’t the GC stop the world?

The GC only pauses the JVM when it has some work to do. Produce less garbage and it will pause less often

Produce less than 1 GB/hour of garbage and you can get less than one pause per day. (With a 24 GB Eden)

Do I need to avoid all objects?

In Java 8 you can have very short lived objects placed on the stack. This requires your code to be inlined and escape analysis to kick in. When this happens, no garbage is created and the code is faster.

You can have very long lived objects, provided you don’t have too much.

The rest of your data you can place in native memory (off heap)

You can create 1 GB/hour of garbage and still not GC

Do I need to avoid all objects?

In Java 8 you can have very short lived objects placed on the stack. This requires your code to be inlined and escape analysis to kick in. When this happens, no garbage is created and the code is faster.

You can have very long lived objects, provided you don’t have too much.

The rest of your data you can place in native memory (off heap)

You can create 1 GB/hour of garbage and still not GC

How does Java 8 avoid creating objects?

One way to think of Java 8 lambdas is the ability to pass behaviour to a library. With inlining, an alternative view is the ability to template your code. Consider this locking example

lock.lock();

try {

doSomething();

} finally {

lock.unlock();

}

How does Java 8 avoid creating objects?

This boiler place can be templatedpublic static void withLock(Lock lock,

Runnable runnable) {

lock.lock();

try {

runnable.run();

} finally {

lock.unlock();

}

}

How does Java 8 avoid creating objects?

This simplifies the code to be

withLock(lock, () -> doSometing());

Doesn’t using a Runnable create an object?

With inlining and escape analysis the Runnable can be placed on the stack and eliminated (as it has no fields)

A low latency with fail over

Data sent between servers is half round trip.

Inputs are written on both servers.

Outputs are written on both servers.

The end to end latency can be 25 µs, 99% of the time.

Demo from http://chronicle.software/products/chronicle-queue/

Next Steps

Chronicle is open source so you can start right away!

Working with clients to produce Chronicle Enterprise

Support contract for Chronicle and consultancy

Q & A

Peter Lawrey

@PeterLawrey

http://chronicle.software

http://vanillajava.blogspot.com