4 ms·

>Closing the market gives participants time to do various kinds of admin related to trading. Trading firms can restart their software to fix the memory leaks.

cwillu 4y ago
Just another generation in the garbage collector.
dahfizz 4y ago
If anyone is wondering, this is not a joke. Some of the trading systems I've worked on were designed to be restarted every night. The memory didn't "leak", but was designed this way - preallocate all the memory you could need, and its "freed" when you restart at night.
- planede 4y ago
  > preallocate all the memory you could need Well, why did they have to restart if they never made any further allocations? This does not add up.
  - dahfizz 4y ago
    Because the memory fills up. You pre-allocate a million orders, and send 800k orders a day, leaving only 200k free slots. You're going to run out mid day tomorrow if you don't restart.
    - planede 4y ago
      Ah, OK. But I would characterize this as an internal allocator that never deallocates. You might as well replace `malloc` and `free` to do the same, and just allocate within the program normally. Just because you "preallocate" it doesn't mean that you don't implement a poor man's allocator inside the preallocated buffer.
      - dahfizz 4y ago
        Sure, but calling malloc at runtime is slow and maintaining an allocator isn't very useful if you can just restart the app every night. YAGNI ;)
    - JamesSwift 4y ago
      That just sounds like a memory leak with more words. Is the memory reclaimed/reclaimable? No? Ok then it leaked. If the system were able to reclaim the memory from the order, you wouldn't need to restart it. The memory arena strategy doesnt change that.
      - TeMPOraL 4y ago
        It's still a fine strategy. One "formal" name for it I've heard is "null garbage collector". It may feel dirty, but it's pragmatic: if the program runs in cycles with well-defined starts and ends, restarting it reclaims all memory and brings the program to a well-known state.
  - LgWoodenBadger 4y ago
    I buy all the groceries I need for a week. That's realistically achievable (cost, cargo capacity of my vehicle, storage capacity at home, etc.). I buy all the groceries I need from now until the end of time. That's not realistically achievable, from any perspective. Allocating all the memory you need for a day is realistically achievable. Allocating all the memory you need until the end of time is not realistically achievable.
    - recursive 4y ago
      The grocery analogy doesn't work. When you're "done" with a particular "grocery", it's gone. It doesn't exist anymore. When you're done using a block of memory, you can use it again and again and again. Assuming you remembered to free it. Groceries work more like write-once memory. Still sounds like a leak to me.
      - TeMPOraL 4y ago
        It's a "leak" only if it creates problems for you, such as slowdown or risk of running out of memory. In this case, there are no such problems - memory use and execution time are both bounded. The memory gets automatically reclaimed when the program restarts (that's the job of the OS, and if it fails at it, you can always reboot the machine). It's a perfectly fine way of engineering a system. There's also a variant of this that's been used on missiles - basically, you put enough RAM on the weapon to guarantee it'll hit its target or run out of fuel before running out of memory.
twic 4y ago
Restarting software once a day to work around memory leaks is real amateur-hour stuff. Mine does it every 10-20 minutes.
- TeMPOraL 4y ago
  The real pros generalized this concept into so-called "supervision trees" - building your system as a hierarchy, where whenever a program misbehaves in any way, it gets restarted by a higher-level program, which itself will also be restarted if it can't get a handle on things, recursively to the top of hierarchy. (Yes, talking about Erlang/OTP here.)
none_to_remain 4y ago
Yep. I once was tracking a white whale of a memory leak. Along the way I was able to optimize memory usage of the leaked objects. So I got to the point where I thought maybe the leak was caused by simultaneous read, update, and delete operations on a single key, but by then I'd improved memory usage such that weekly, rather than nightly restarts were needed. The futures markets at the time were 24/7 but with a maintenance period on the weekends, so my boss just told me to leave it and let the restarts garbage collect.

cwillu 4y ago

Just another generation in the garbage collector.

dahfizz 4y ago

If anyone is wondering, this is not a joke. Some of the trading systems I've worked on were designed to be restarted every night. The memory didn't "leak", but was designed this way - preallocate all the memory you could need, and its "freed" when you restart at night.

planede 4y ago
> preallocate all the memory you could need Well, why did they have to restart if they never made any further allocations? This does not add up.
- dahfizz 4y ago
  Because the memory fills up. You pre-allocate a million orders, and send 800k orders a day, leaving only 200k free slots. You're going to run out mid day tomorrow if you don't restart.
  - planede 4y ago
    Ah, OK. But I would characterize this as an internal allocator that never deallocates. You might as well replace `malloc` and `free` to do the same, and just allocate within the program normally. Just because you "preallocate" it doesn't mean that you don't implement a poor man's allocator inside the preallocated buffer.
    - dahfizz 4y ago
      Sure, but calling malloc at runtime is slow and maintaining an allocator isn't very useful if you can just restart the app every night. YAGNI ;)
  - JamesSwift 4y ago
    That just sounds like a memory leak with more words. Is the memory reclaimed/reclaimable? No? Ok then it leaked. If the system were able to reclaim the memory from the order, you wouldn't need to restart it. The memory arena strategy doesnt change that.
    - TeMPOraL 4y ago
      It's still a fine strategy. One "formal" name for it I've heard is "null garbage collector". It may feel dirty, but it's pragmatic: if the program runs in cycles with well-defined starts and ends, restarting it reclaims all memory and brings the program to a well-known state.
- LgWoodenBadger 4y ago
  I buy all the groceries I need for a week. That's realistically achievable (cost, cargo capacity of my vehicle, storage capacity at home, etc.). I buy all the groceries I need from now until the end of time. That's not realistically achievable, from any perspective. Allocating all the memory you need for a day is realistically achievable. Allocating all the memory you need until the end of time is not realistically achievable.
  - recursive 4y ago
    The grocery analogy doesn't work. When you're "done" with a particular "grocery", it's gone. It doesn't exist anymore. When you're done using a block of memory, you can use it again and again and again. Assuming you remembered to free it. Groceries work more like write-once memory. Still sounds like a leak to me.
    - TeMPOraL 4y ago
      It's a "leak" only if it creates problems for you, such as slowdown or risk of running out of memory. In this case, there are no such problems - memory use and execution time are both bounded. The memory gets automatically reclaimed when the program restarts (that's the job of the OS, and if it fails at it, you can always reboot the machine). It's a perfectly fine way of engineering a system. There's also a variant of this that's been used on missiles - basically, you put enough RAM on the weapon to guarantee it'll hit its target or run out of fuel before running out of memory.

twic 4y ago

Restarting software once a day to work around memory leaks is real amateur-hour stuff. Mine does it every 10-20 minutes.

TeMPOraL 4y ago
The real pros generalized this concept into so-called "supervision trees" - building your system as a hierarchy, where whenever a program misbehaves in any way, it gets restarted by a higher-level program, which itself will also be restarted if it can't get a handle on things, recursively to the top of hierarchy. (Yes, talking about Erlang/OTP here.)

none_to_remain 4y ago

Yep. I once was tracking a white whale of a memory leak. Along the way I was able to optimize memory usage of the leaked objects. So I got to the point where I thought maybe the leak was caused by simultaneous read, update, and delete operations on a single key, but by then I'd improved memory usage such that weekly, rather than nightly restarts were needed. The futures markets at the time were 24/7 but with a maintenance period on the weekends, so my boss just told me to leave it and let the restarts garbage collect.