5 ms·

> Who was it that turned GC off entirely, minimized allocation and just restarted their VMs when they ran out of RAM every couple of hours, was that Netflix? T

by nvarsj 6y ago

> Who was it that turned GC off entirely, minimized allocation and just restarted their VMs when they ran out of RAM every couple of hours, was that Netflix? This was common practice in trading firms that got on the Java hype train. Turn off GC and just restart the JVM outside of trading hours. > Either way. It makes me excited for Rust and the languages it'll inspire, all this labor gone away. The JVM gives GC a bad name. There are plenty of GC languages which don’t have the level of pain of hotspot except in extreme cases. For the vast majority of GC languages you never even think about it. Rust / C++ are great when you need full control but it’s not necessary for most things.

darksaints 6y ago
I'd say it's more the language design than anything. Heap allocating everything, and then throwing in inheritance 30 levels deep makes for some very poor GC behavior.
- wokkel 6y ago
  What relationship do you see between inheritance and GC ? Creating An instance of some object 30 levels deep in the inheritance chain does not allocate 29 extra objects.
  - darksaints 6y ago
    It's not always that simple. For example, if you inherit from a class that has private members, you are actually going to allocate both the parent and child. https://stackoverflow.com/questions/27813539/what-happens-in-the-heap-when-class-a-inherits-class-b-in-java https://stackoverflow.com/questions/27813539/what-happens-in... Also, if you don't mark your methods and classes as final, you're gonna be allocating functions everywhere as well.
    - haxen 6y ago
      > you are actually going to allocate both the parent and child. You're going to allocate a single memory block that contains all the state of that object, which of course includes the superclass state. But that has nothing to do with the depth of the class hiererarchy. > you're gonna be allocating functions everywhere as well. If by "function" you mean a "Java method", they are code and not data, and they are not allocated dynamically at all. In any case, this would have nothing to do with them being private or final. These options decide whether there will be an invokevirtual or invokespecial instruction to call them, where invokevirtual has more cost only before getting JIT-optimized.
pron 6y ago
No runtime has a better GC than Java's, certainly in the current version (14) which is worlds better than Java 8. The reason you don't think about it in other languages is because if you use other languages, you probably don't care too much about performance in the first place.
- cogman10 6y ago
  * better GCs (plural) Probably the best thing about the JVM that, AFAIK, no other platform does is it gives you an option for which GC you use. Not only is that an option, but you are spoiled with options. ZGC, G1GC, Shenandoah, The parallel collector, the serial collector. Pick the right one for the job! But beyond that, they are infinitely tuneable (Not that you should usually). Again, not something that almost any other platform offers.
- nvarsj 6y ago
  So if I care about performance, I would use the JVM? I spent years as a performance engineer on HFT trading systems tuning JVMs. It’s possible to get very good performance on the JVM, but it is also hard and for the layman almost impossible. Yes, it has great throughput, but only because it has to. The design of hotspot / JVM and the languages that run on it encourages massive heap allocations of gigabytes a second. I can’t think of any other language or runtime that is comparable in terms of its memory bloat. Even if you control allocations, and have happy path GCs, hotspot GC still causes occasional pauses of 10-100s milliseconds. And this is considered good. I know that lots of people have built careers on the JVM and defend it vigorously. Whenever I make a comment that is negative on the JVM, I always get downvoted without fail on HN. I used to be one of these people, after all, so I can relate. If I truly cared about performance these days, I’d use C++ or Rust. Otherwise, I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. I think even most scripting languages, like Ruby/Python, have reasonable memory usage and GC patterns for web development, but I’m not as familiar with them. I probably care more about energy consumption these days though. And again, the JVM is the worst offender. The average developer building a Java web app will create something which consumes gigabytes of memory usually. These apps tend to spend the majority of their CPU time allocating and GCing memory. I can only guess how much server time has been consumed to satiate the memory hungry needs of the JVM.

by nvarsj 6y ago

darksaints 6y ago

I'd say it's more the language design than anything. Heap allocating everything, and then throwing in inheritance 30 levels deep makes for some very poor GC behavior.

wokkel 6y ago
What relationship do you see between inheritance and GC ? Creating An instance of some object 30 levels deep in the inheritance chain does not allocate 29 extra objects.
- darksaints 6y ago
  It's not always that simple. For example, if you inherit from a class that has private members, you are actually going to allocate both the parent and child. https://stackoverflow.com/questions/27813539/what-happens-in-the-heap-when-class-a-inherits-class-b-in-java https://stackoverflow.com/questions/27813539/what-happens-in... Also, if you don't mark your methods and classes as final, you're gonna be allocating functions everywhere as well.
  - haxen 6y ago
    > you are actually going to allocate both the parent and child. You're going to allocate a single memory block that contains all the state of that object, which of course includes the superclass state. But that has nothing to do with the depth of the class hiererarchy. > you're gonna be allocating functions everywhere as well. If by "function" you mean a "Java method", they are code and not data, and they are not allocated dynamically at all. In any case, this would have nothing to do with them being private or final. These options decide whether there will be an invokevirtual or invokespecial instruction to call them, where invokevirtual has more cost only before getting JIT-optimized.

pron 6y ago

No runtime has a better GC than Java's, certainly in the current version (14) which is worlds better than Java 8. The reason you don't think about it in other languages is because if you use other languages, you probably don't care too much about performance in the first place.

cogman10 6y ago
* better GCs (plural) Probably the best thing about the JVM that, AFAIK, no other platform does is it gives you an option for which GC you use. Not only is that an option, but you are spoiled with options. ZGC, G1GC, Shenandoah, The parallel collector, the serial collector. Pick the right one for the job! But beyond that, they are infinitely tuneable (Not that you should usually). Again, not something that almost any other platform offers.
nvarsj 6y ago
So if I care about performance, I would use the JVM? I spent years as a performance engineer on HFT trading systems tuning JVMs. It’s possible to get very good performance on the JVM, but it is also hard and for the layman almost impossible. Yes, it has great throughput, but only because it has to. The design of hotspot / JVM and the languages that run on it encourages massive heap allocations of gigabytes a second. I can’t think of any other language or runtime that is comparable in terms of its memory bloat. Even if you control allocations, and have happy path GCs, hotspot GC still causes occasional pauses of 10-100s milliseconds. And this is considered good. I know that lots of people have built careers on the JVM and defend it vigorously. Whenever I make a comment that is negative on the JVM, I always get downvoted without fail on HN. I used to be one of these people, after all, so I can relate. If I truly cared about performance these days, I’d use C++ or Rust. Otherwise, I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. I think even most scripting languages, like Ruby/Python, have reasonable memory usage and GC patterns for web development, but I’m not as familiar with them. I probably care more about energy consumption these days though. And again, the JVM is the worst offender. The average developer building a Java web app will create something which consumes gigabytes of memory usually. These apps tend to spend the majority of their CPU time allocating and GCing memory. I can only guess how much server time has been consumed to satiate the memory hungry needs of the JVM.