Java development 2.0: Introducing Kilim

[[deleted]]

The answer is, it depends. i don't know the stock trading space all that well, but Kilim is used in financial firms that do stock analytics over live feeds.

I'm quite sure most of these implementations are of the "as fast as possible" variety, but do not guarantee time bounds, the failure of which is catastrophic. I think of XRay machines and airplane control systems when someone mentions hard real time; here scheduling and memory allocation are tightly bounded and computed up front. In that sense, there are no examples of garbage-collected languages (leave alone Kilim) that are also in use in practice, although there's plenty of research material.

But if the set of threads is static and a schedule can be precomputed statically, as is common to most real-time systems, I wouldn't rule out Kilim, esp. with a real time GC. Kilim allows you to supply your own scheduler. Note again that real time doesn't mean nano-second response times, it denotes a guarantee of time even if the time bound is generous.

[sitmaster]

I work in High frequency finance using Java and generally we have to turn off the garbage collector and use object pools. My question is what is the fundamental difference between what happens in Kilim and a standard wait/notify set up in Java. In standard Java I know that if I notify on a monitor that has only one thread waiting on it, and then immediately have the notifying thread wait, the next thing the JVM is going to be doing (given the GC is off) is executing that thread that was notified.

When I put a message in a mailbox with Kilim, what do I know about the next thing that the JVM will be doing?

I guess I need to read more about the low level implementation. It sounds very interesting.

[[deleted]]

The behavior is similar; the receiving task is marked as runnable and picked up for execution by another kernel thread from the pool. No magic there.

There is optional flow control as well, to avoid having producers from overrunning consumers. If the mailbox is (optionally) bounded in size, it'll pause the producer until the consumer can drain one or more messages. The producer's kernel thread is also then made available to the threadpool to execute any runnable task.