4 ms·

Java will use as much memory as you give it. Because you told it to use that much, and using more generally gives better performance. "Native" or not has nothi

• stiray 5y ago
  Please check this, it explain difference between Java and Go garbage collectors quite nicely: https://itnext.io/go-does-not-need-a-java-style-gc-ac99b8d26c60 https://itnext.io/go-does-not-need-a-java-style-gc-ac99b8d26...
  • kaba0 5y ago
    It was criticized quite heavily on the relevant hn thread. But basically, go can get away with a less advanced GC due to having and relying on value types quite often. But Java and certain workloads do require the state-of-the-art GCs that the JVM provides. And a search engine likely constitutes such a one.
  • pkulak 5y ago
    Yeah... I guess. But I could write the same article about how Java doesn't need value types and extreme escape analysis because it has a generational garbage collector. 99% of garbage really does end up in the eden generation and is literally free to clean up, no different than a stack. Once you put aside all the words and see how things stack up in the real world, Go and Java are pretty comparable, usually with the JVM having a slight edge after the JIT is nice and warm. They go about it in different ways, but there's nothing wrong with that.
• tomohawk 5y ago
  And then some. Elasticsearch restarting due to out of memory errors was a common occurrence at my last gig where we used it heavily. The difference between Java GC and Go GC is stark. In several years, I've never had to touch a GC knob on Go, but in Java it is expected, and not usually worth the effort.
  • kaba0 5y ago
    It is not expected at all in like a decade (and even previously, it was mostly blog articles for very specific workloads, being out of date soon after publication). The default G1 GC is perfectly fine for the vast majority of workloads as is. In the rare case it is needed, the target pause time setting can be used to swift our preference of latency vs throughput.