[en4bz]

That removes the value proposition of Java though which is that you don't need to worry about memory management. If you need to mentally track every implicit allocation and deallocation in Java then you are essentially writing code in a kneecapped version of C++.

[amarkov]

Even in a database, most of the code isn't performance sensitive. Making your life a bit harder in the fast path so it's easier in the slow path is at least a tradeoff worth considering.

[kllrnohj]

Your fast path is still crippled by your slow paths' mess. It doesn't matter if you've isolated and optimized those paths in isolation, to the GC there's just Your Process and it's going to suspend Your Process whenever it wants for however long it needs regardless of what's currently happening.

So if you're latency sensitive then all of your code needs to be aggressive at avoiding object creation. All of your code becomes part of "the fast path", even if it's in a different thread.

Or you isolate your fast path in a different process or a non-GC'd runtime, the later being the approach taken here by Instagram.

[majidazimi]

Based on previous research [1], almost every part of a DB is in the hot path.

[1] http://15721.courses.cs.cmu.edu/spring2018/papers/02-inmemor...

[amarkov]

I'd definitely believe that every part of query execution is in the hot path, as this paper describes. But most code in any reasonable DB system isn't part of query execution.

[mschuster91]

> If you need to mentally track every implicit allocation and deallocation in Java then you are essentially writing code in a kneecapped version of C++.

Well, Java has the advantage of being platform (and to a certain degree, runtime) independent, plus a robust set of best practices and ecosystem when it comes to modules and library handling, which is pretty hard to get done right for C/C++ projects.

[en4bz]

Node.js is also platform independent and has a package manager but I wouldn't use it for a High Performance / Low Latency application like a database.

[majidazimi]

> Well, Java has the advantage of being platform (and to a certain degree, runtime) independent

What is the benefit of that? Who on earth runs a DB written in Java on windows? Any useful server software will end up using platform native features, be it SQL server, MySQL, HBase, ...

[mschuster91]

> Who on earth runs a DB written in Java on windows?

There still are lots of Windows-only shops.

[itronitron]

developing in Java with awareness of the GC doesn't mean tracking allocation and deallocation of memory, it means developers should avoid allocating lots of new Objects when possible. In practice this means creating view, cursor, or offset type Objects that map to arrays of more primitive data types.

[tibbetts]

Exactly. Developing GC aware code is still easier and safer than c++ memory management. Particularly because when you screw up in c++ you get crashes or data loss, and when you screw up in Java you mostly just get GC pauses.

[MaxBarraclough]

Mandatory mention of D and its @nogc feature (as it sounds, a compile-time guarantee that a function doesn't allocate on the garbage-collected heap)

https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/