6 ms·

I have to admit that I have never built a large scale system, but with small to medium scale systems I have always ended up tuning GC parameters and looking for

I have to admit that I have never built a large scale system, but with small to medium scale systems I have always ended up tuning GC parameters and looking for stray references. And of course there is always some piece of code that depends on finalizers to close some resource, so not doing enough GC a problem just as much as doing too much of it. In my current project (C#) there's the additional problem that there are situations where GC just isn't allowed but there are some language features that just create objects behind the scenes without any warning. So yes, it's not impossible to achieve but it's a lot more difficult than dealing with reference counting or C++ smart pointers.

Tainnor 5y ago
> And of course there is always some piece of code that depends on finalizers to close some resource [...] I don't think anyone should use finalizers in Java. It's been deprecated since Java 9 and even before that, it was widely considered a bad practice.
- oriolid 5y ago
  I don't think anyone should use finalizers in Java either, but it hasn't stopped anyone from doing that.
  - Tainnor 5y ago
    There are footguns in every language. There are certainly more footguns in C, which you're trying to advocate for, if I understand correctly (although I'm really not sure what your point is). FWIW, I haven't ever seen anyone use finalize() in Java. I don't doubt that it happens occasionally, but you can't blame a language for some of its users being incompetent.
    - oriolid 5y ago
      I'm not advocating C for anything except low-level embedded but even there I think we could do better. I'm not sure what would be the optimal language for writing web backends but I'm convinced that we could do better than Java. I could even go as far as claiming that C# is a lot like Java with some of the worst parts fixed.
  - pjmlp 5y ago
    In the next LTS release it won't matter, as they won't be around any longer. https://openjdk.java.net/jeps/421 https://openjdk.java.net/jeps/421
cogman10 5y ago
> I have always ended up tuning GC parameters and looking for stray references. I've been doing java for years and the key I've learned about the JVM is to stop tuning GC parameters. The JVM has incredibly good heuristics provided you let them work. The most you should generally do is pick the algorithm and the heap size (maybe the pause time) doing more should only be done if you've got a large amount of evidence (GClogs) to support such changes. Way too many people shoot themselves in the foot trying to hand craft GC settings. Beyond that, I've found that application changes are almost always more effective than GC changes. Use the JVMs fantastic telemetry tools (Java flight recorder) and find out what's really going on with your application. Again, grab the data first, optimize, and then remeasure to see what's next. I've managed plenty of apps with 30+gb heaps and 0 tuning.
- deleted 5y ago
  [deleted]
- oriolid 5y ago
  I wish I could say the same. Most times it ended up one of two ways: Either the app is stuck doing GC, or it crashes with OutOfMemoryError: too many this or that handles, open pipes or something else.
  - Tainnor 5y ago
    I don't know what kinds of things you're doing on the JVM, but the only situations where I've seen these kinds of errors were either a) batch jobs on massive amounts of data (which yeah... it figures that they could OOM, not sure how you'd prevent that), or b) a serious error in application logic. In general, I don't really encounter these problems and neither do most other people who write for the JVM.
    - pjmlp 5y ago
      Same here, usually you get that from code that uses new everywhere without any kind of thought regarding proper use of algorithms and data structures.
  - 5y ago

Tainnor 5y ago

> And of course there is always some piece of code that depends on finalizers to close some resource [...] I don't think anyone should use finalizers in Java. It's been deprecated since Java 9 and even before that, it was widely considered a bad practice.

oriolid 5y ago
I don't think anyone should use finalizers in Java either, but it hasn't stopped anyone from doing that.
- Tainnor 5y ago
  There are footguns in every language. There are certainly more footguns in C, which you're trying to advocate for, if I understand correctly (although I'm really not sure what your point is). FWIW, I haven't ever seen anyone use finalize() in Java. I don't doubt that it happens occasionally, but you can't blame a language for some of its users being incompetent.
  - oriolid 5y ago
    I'm not advocating C for anything except low-level embedded but even there I think we could do better. I'm not sure what would be the optimal language for writing web backends but I'm convinced that we could do better than Java. I could even go as far as claiming that C# is a lot like Java with some of the worst parts fixed.
- pjmlp 5y ago
  In the next LTS release it won't matter, as they won't be around any longer. https://openjdk.java.net/jeps/421 https://openjdk.java.net/jeps/421

cogman10 5y ago

> I have always ended up tuning GC parameters and looking for stray references. I've been doing java for years and the key I've learned about the JVM is to stop tuning GC parameters. The JVM has incredibly good heuristics provided you let them work. The most you should generally do is pick the algorithm and the heap size (maybe the pause time) doing more should only be done if you've got a large amount of evidence (GClogs) to support such changes. Way too many people shoot themselves in the foot trying to hand craft GC settings. Beyond that, I've found that application changes are almost always more effective than GC changes. Use the JVMs fantastic telemetry tools (Java flight recorder) and find out what's really going on with your application. Again, grab the data first, optimize, and then remeasure to see what's next. I've managed plenty of apps with 30+gb heaps and 0 tuning.

deleted 5y ago
[deleted]
oriolid 5y ago
I wish I could say the same. Most times it ended up one of two ways: Either the app is stuck doing GC, or it crashes with OutOfMemoryError: too many this or that handles, open pipes or something else.
- Tainnor 5y ago
  I don't know what kinds of things you're doing on the JVM, but the only situations where I've seen these kinds of errors were either a) batch jobs on massive amounts of data (which yeah... it figures that they could OOM, not sure how you'd prevent that), or b) a serious error in application logic. In general, I don't really encounter these problems and neither do most other people who write for the JVM.
  - pjmlp 5y ago
    Same here, usually you get that from code that uses new everywhere without any kind of thought regarding proper use of algorithms and data structures.
- 5y ago