[pkolaczk]

The trick is, when you have deterministic destruction you can use it for many more things than just memory management. E.g. need to add a metric to measure how many "somethings" are active - just attach a tracker to the struct representing that "something" and the tracker can count itself because it knows exactly when it is created and destroyed. We tried to add such metrics system to a Java app another day, and it turned out to be virtually impossible because due to GC nondeterminism we couldn't tell when most of the objects die.

[UltraViolence]

Do you really need to know? All that matters is that the GC will eventually clean up the used memory. When you're interested in that sort of info you're using the wrong language or asking the wrong kind of questions.

[jandrewrogers]

It comes up quite a lot in things like databases and high-performance data infrastructure generally. The instantaneous resource state is an important input parameter to many types of dynamic optimization. Ideally, you want to run close to the resource limits without exceeding them for maximum throughput and robustness while minimizing tail latencies. Knowing precisely how many resources are available allows the code to opportunistically apply that capacity to workload optimization without risking resource starvation. Some software will also adaptively switch entire strategies based on this information. It is very useful information if you are designing for performance.

If you have no idea how many resources are actually available, you are forced to use conservative strategies to protect the process. Guessing or ignoring resource availability is an excellent way to greatly increase performance variability and reduce throughput.

[pkolaczk]

Yes, of course I need to know. An important part of production grade software is observability. And that "something" doesn't have to be memory. It can be a connection, file handle, semaphore permit or one of many other things. But even for memory, typically there is not just one global type of memory. Users want to know how much memory is dedicated to X, Y and Z components, they might also want to constrain memory use by logical function. E.g separate buffer pools. This is where automatic memory management with GC falls apart very quickly - even the Java apps I work on actually use a memory/resource abstraction layer on top and manage everything manually, leaving just the last bit of releasing the objects to GC. Which is the worst of both worlds - we get all the disadvantages of MMM and all disadvantages of tracing (pauses, cache thrashing, etc).

[Jensson]

Java doesn't sound right for your use case. Most programs written in Java works just fine without tracking memory, and if you have any issues you do a jvm memory dump to see which object types are taking up all that memory and then look at why they weren't collected.

[pkolaczk]

Sure, I know that. But sometimes you don't have a choice because the decision was made years earlier by someone else, and you obviously won't rewrite a 1M LOC codebase.

Nevertheless, after spending a year writing Rust, I'd take Rust over Java for just any use case now, even including CRUDs and GUIs (actually doing a GTK GUI for a Rust app right now, and it is not any worse in terms of dev speed than Java Swing was, despite what people say about callbacks - I really don't mind an occasional Rc/Refcell/clone here and there).

[lelanthran]

>> need to [...] attach a tracker to the struct representing that "something" and the tracker can count itself because it knows exactly when it is created and destroyed.

> Do you really need to know?

He, uh, just said that. If you're tracking profiling metrics like he is (lifetime of a call-stack, maybe?), you need to know.

> When you're interested in that sort of info you're using the wrong language

Under that argument, Java is the wrong language for everything.