4 ms·

High frequency traders are able to avoid JVM garbage collection during the trading day by just holding off until the market is closed.

Retr0spectrum 10y ago
Do you have a source for that? It's an interesting idea.
- kasey_junk 10y ago
  I don't have a source but I did it when I worked in HFT & it wasn't novel.
- hyperpape 10y ago
  You can probably find discussions if you dig around in the mechanical sympathy mailing list. My impression, btw, is that it still requires pretty significant efforts to control allocation. I'm not sure there's a 1-1 match, but I associate it with people writing custom substitutes for java.lang.String to avoid allocations.
- ramchip 10y ago
  I worked at a bank and saw that pattern used in market connection middleware as well. It's really common, but since that stuff is all closed source it's hard to point to a concrete example. (The thing was also optimized to reuse objects to allocate as little as possible... but a writeup from that team on an internal website said, basically, that Java GC was so efficient nowadays that it may not have been worth the extra maintenance effort and potential for bugs, in retrospect)
maaaats 10y ago
Same for games written i Java, by using pooling and not deallocating until a safe spot. Was especially important in early Android, where a GC break would not just feel like minor lag, but actally make a really big stutter.
- kevin_nisbet 10y ago
  I used object pooling as a technique to increase performance on some of the tools I wrote in my previous role. These were protocol analysis tools, used for monitoring network links, and it was an order of magnitude increase in performance by pooling most objects, and reducing the work of the GC. For performance critical code in a managed language, it made an astonishing difference, at least in my use case.
- 0xcde4c3db 10y ago
  Similarly, many old C and assembly games just have static arrays for a sufficiently large number of each type and allocate from that using some simple scheme (e.g. slot count + compacting, bitmap, used/unused bit in the data structure itself, etc.).
carterehsmith 10y ago
Ha, nice. BTW, I think that many of us use the same 'technique' by accident :) As in, if you deploy often enough, you may never notice that your app has a memory leak.

Retr0spectrum 10y ago

Do you have a source for that? It's an interesting idea.

kasey_junk 10y ago
I don't have a source but I did it when I worked in HFT & it wasn't novel.
hyperpape 10y ago
You can probably find discussions if you dig around in the mechanical sympathy mailing list. My impression, btw, is that it still requires pretty significant efforts to control allocation. I'm not sure there's a 1-1 match, but I associate it with people writing custom substitutes for java.lang.String to avoid allocations.
ramchip 10y ago
I worked at a bank and saw that pattern used in market connection middleware as well. It's really common, but since that stuff is all closed source it's hard to point to a concrete example. (The thing was also optimized to reuse objects to allocate as little as possible... but a writeup from that team on an internal website said, basically, that Java GC was so efficient nowadays that it may not have been worth the extra maintenance effort and potential for bugs, in retrospect)

maaaats 10y ago

Same for games written i Java, by using pooling and not deallocating until a safe spot. Was especially important in early Android, where a GC break would not just feel like minor lag, but actally make a really big stutter.

kevin_nisbet 10y ago
I used object pooling as a technique to increase performance on some of the tools I wrote in my previous role. These were protocol analysis tools, used for monitoring network links, and it was an order of magnitude increase in performance by pooling most objects, and reducing the work of the GC. For performance critical code in a managed language, it made an astonishing difference, at least in my use case.
0xcde4c3db 10y ago
Similarly, many old C and assembly games just have static arrays for a sufficiently large number of each type and allocate from that using some simple scheme (e.g. slot count + compacting, bitmap, used/unused bit in the data structure itself, etc.).

carterehsmith 10y ago

Ha, nice. BTW, I think that many of us use the same 'technique' by accident :) As in, if you deploy often enough, you may never notice that your app has a memory leak.