This is a great thread and has a lot of good information in it; thank you. As someone mentioned, there won't be a one-size-fits-all solution. Even a pause of hundreds of micros can be too long for some automated trading systems. However there are several firms that use managed languages for these systems and the 'trick' is that you manage allocation and garbage very carefully. Large heaps, Garbage-free algorithms, object pools, off-heap memory, etc are all employed (similar to a hard real-time process) so that a stop-the-world collection never happens. For long-running systems you can designate a maintenance period where you can run a stop-the-world collection on demand.
So do your best to accommodate the common case and if some developer of ultra-low-latency applications wants to use your language leave it up to them to manage the latency - that's their job. What I like to see is an API to a garbage collector such that you can turn it on or off, maybe some knobs to influence the algorithm for your specific use case. The hardware matters, the native OS matters, and you must be in as much control as possible of every step in the path from the reception of a packet through your logic and the transmission of your own packets. The only garbage collector that will be a problem in that domain is one that you can't control. That's why we want a systems programming language, right? control? Garbage collection should be considered an opt-in service with your choice of providers :) That's one of the things I like about Rust and ATS... it's very clear when you're using the garbage collector and it's your choice to use it or not. I hope that BitC goes the same route. -ipc _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
