Hacker News new | past | comments | ask | show | jobs | submit login

Ive worked a couple java based hft platforms at major firms. You write code that never gcs after startup. That means not using certain language constructs and rewriting almost every library along with using off heap memory.

I have personally worked on systems that would run an entire week between deployments and never gced.






Could you maybe elaborate more on how to achieve this with Java, i.e., run an entire week and never get GCed? I would imagine that using immutable types is one of the tricks used in such a scenario.

You would (among other techniques) use something like Stormpot to maintain Object pools to release and acquire instances from.

Object pools typically can't match the GC on latency and throughput, however they do provide a lot more predictable and stable performance.


You basically write Java as C++, you don't use any builtins, write everything yourself from pure java.

I know you said "almost" but you don't have to re-write huge amounts to achieve zero gc and very low latency. There are open source tools, eg. agrona, aeron, that get you a lot of the way there.

And I'd imagine sun.misc.Unsafe is used quite often too.

Why would you do that? Why not use C++? Especially, as you say, when memory management is ignored...

You can use a language like OCaml without allocating and still capture huge benefits over C++, like a decent type system, ADTs, and better abstractions than templates (modules in OCaml's case).

What about multicore? :)

Nowadays Rust seems to cover all those features with zero-cost abstractions.


You still need to write non-consing code to avoid memory allocation/deallocation latency, just as if you were working in Java, Lisp or OCaml.

(In fact, GCs can often give you better latency than malloc/free unless you go into custom allocators with object pools... which is part of writing non-consing code in GCed languages)


Ah you're right, I forgot about OCaml's ass-tier multicore support. Rust is definitely better there.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: