12 ms·

Im more skeptical. one of the reasons we're still on jre8 is any of the newer jres I tested throw crash panics on several tasks and the ones that dont take 40 o

Im more skeptical. one of the reasons we're still on jre8 is any of the newer jres I tested throw crash panics on several tasks and the ones that dont take 40 or 50 hours to finish instead of instead of 4 or 5. (mostly changes in the garbage collection as far as i could tell, several command line options we rely on for performance were depreciated with no way to turn them back on) That left me with the impression that stability and performance had been abandoned over throwing everything including the kitchen sink at it to try and attract people who like rust and go. Could be wrong, but the hand waving away the implication that 17 is slower than 15 at the end and not even trying to compare with 8 which is rock solid and crazy performant leaves me thinking nothing actually changed.

vips7L 5y ago
Here is a blog that compares garbage collection across several versions and GC's: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 They concluded: "JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses."
- DarkmSparks 5y ago
  I forget, bit iirc it uses one by default, but you can specify the number of threads to use with XX:ParallelGCThreads=<N> which is what got depreciated later. its target is throughput rather than response so yep "pauses", but the entire job takes 4 hours instead of 40. In production those pauses vanish with load balancing. checking for jdk8 vs jdk17 turns up https://www.google.com/amp/s/www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.amp.html https://www.google.com/amp/s/www.infoworld.com/article/36068... "New Relic found that nearly 100 percent of users are running either JDK 11 or JDK 8, the two most recent LTS releases." so 17 being 8% faster than 11 apart from when its 10% slower, "maybe" slower or faster than 15 but they chose not to do a like for like comparison.... but 11 being catastrophically lower throughput than 8.... I may get some time soon to do some benching, I dont want to be back on 8, but the benching I did for at least 10 and 11 just made them a no go, completely crashing the jvm was an even bigger issue than the time.
  - hilbertseries 5y ago
    Are you sure ParallelGCThreads was deprecated? The cms GC algorithm was deprecated but that doesn’t use that setting, which is used by the ParallelGC algorithm. The default was changed to the g1gc algorithm. But if you were manually specifying parallelgc that shouldn’t have been impacted.
    - DarkmSparks 5y ago
      >Are you sure ParallelGCThreads was deprecated? Definitely not sure it was that op exactly, reasonably sure it was something related to it (maybe it no longer working with a gc it used to). TLDR:I found out "the hard way" -XX means "jvm specific, can change meaning at any time and is jvm vendor specific". oracle java 8 had a sweet spot that made perf awesome, nothing since has come close.
- zz865 5y ago
  G1 uses a lot more memory than CMS so we can't upgrade that. Is deprecated on 11 but we still use it.
pron 5y ago
The current JDKs are at least as stable and, for most workloads, significantly more performant and less RAM-hungry than 8. JDK 8 is medieval technology compared to the modern JDK. The savings in hardware alone pay for the cost of migration within less than a year.
- DarkmSparks 5y ago
  Yes i did see the "less ram hungry" thought that may actually be part of the issue - not keeping things that benefited from that persistence around long enough. Traded throughput away for smaller lookup tables. As for "medieval technology" in what way? If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward?
  - pron 5y ago
    > Traded throughput away for smaller lookup tables. Much of the improvement came from a re-encoding of String (no longer internally encoded as UTF-16), and more sophisticated GC algorithms. > If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward? If you see crashes, submit a bug report, but we've not been seeing any increase in crash reports. It's possible that you're using a library that hacks into JDK internals and is a cause of such problems. Try using JDK 16 or 17, where strong encapsulation is turned on (at least by default).
    - DarkmSparks 5y ago
      Those crashes were just on our unit tests, creating linking and destroying large volumes of objects, throwing them in a thread for some basic compute then writing results to disk. I agree its really about the gc, but the new ones just never seemed to beat the setup we have on 8, and there is only so much time that can be devoted to making things that work, work on "new shiney". java after 8 is just mayhem, before it was easy, oracle for some things, ibm for others. now there are new long term releases faster than we can test them, they fail at least one of the unit tests that all pass on 8, and openjdk is missing half the really nice stuff that was once free. >submit a bug report but to who and under what title? Oracle, IBM, openjdk? e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?
ashtonkem 5y ago
Must be something unique in your workload. For my team, later versions of Java have been stable and a bit faster than older versions.
krzyk 5y ago
jdk 8 is not rock solid nor performant. You should look at your codebase, you might be doing some strange things that changed in newer JDKs (e. g. String split no longer uses the sour String, but I don't remember when they changed that). Some options were deprecated because they are also always on (not all probably).
- DarkmSparks 5y ago
  3 years uninterupted uptime and counting. what in 17 do you think is worth risking downtime?
  - fridif 5y ago
    Nothing for you, but something for us.
  - sigzero 5y ago
    Why would there be downtime? It's faster. Less RAM hungry. Tons of new great features. I mean, if you don't want or feel the need to upgrade then don't. There are plenty of reasons to do so IMO.
    - DarkmSparks 5y ago
      Because the core system dates back to jre... 1.4, has had ~2 decades of painful testing and big chunks of code dont currently work on anything newer than 8. a bug that takes 100 hours to manifest takes multiples of that to fix. compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
      - stuff4ben 5y ago
        Yeah I'm gonna say you're an edge case and that the majority of users will see performance benefits. Maybe not you, but that's legacy code for ya and an awful lot of technical debt that's likely not worth it.
deleted 5y ago
[deleted]
hyperpape 5y ago
The magnitude of the change should tell you that you're hitting a weird edge case. Obviously new versions of the jre are not going to be 10x slower in general.

vips7L 5y ago

Here is a blog that compares garbage collection across several versions and GC's: https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 https://jet-start.sh/blog/2020/06/09/jdk-gc-benchmarks-part1 They concluded: "JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses."

DarkmSparks 5y ago
I forget, bit iirc it uses one by default, but you can specify the number of threads to use with XX:ParallelGCThreads=<N> which is what got depreciated later. its target is throughput rather than response so yep "pauses", but the entire job takes 4 hours instead of 40. In production those pauses vanish with load balancing. checking for jdk8 vs jdk17 turns up https://www.google.com/amp/s/www.infoworld.com/article/3606833/jdk-17-the-new-features-in-java-17.amp.html https://www.google.com/amp/s/www.infoworld.com/article/36068... "New Relic found that nearly 100 percent of users are running either JDK 11 or JDK 8, the two most recent LTS releases." so 17 being 8% faster than 11 apart from when its 10% slower, "maybe" slower or faster than 15 but they chose not to do a like for like comparison.... but 11 being catastrophically lower throughput than 8.... I may get some time soon to do some benching, I dont want to be back on 8, but the benching I did for at least 10 and 11 just made them a no go, completely crashing the jvm was an even bigger issue than the time.
- hilbertseries 5y ago
  Are you sure ParallelGCThreads was deprecated? The cms GC algorithm was deprecated but that doesn’t use that setting, which is used by the ParallelGC algorithm. The default was changed to the g1gc algorithm. But if you were manually specifying parallelgc that shouldn’t have been impacted.
  - DarkmSparks 5y ago
    >Are you sure ParallelGCThreads was deprecated? Definitely not sure it was that op exactly, reasonably sure it was something related to it (maybe it no longer working with a gc it used to). TLDR:I found out "the hard way" -XX means "jvm specific, can change meaning at any time and is jvm vendor specific". oracle java 8 had a sweet spot that made perf awesome, nothing since has come close.
zz865 5y ago
G1 uses a lot more memory than CMS so we can't upgrade that. Is deprecated on 11 but we still use it.

pron 5y ago

The current JDKs are at least as stable and, for most workloads, significantly more performant and less RAM-hungry than 8. JDK 8 is medieval technology compared to the modern JDK. The savings in hardware alone pay for the cost of migration within less than a year.

DarkmSparks 5y ago
Yes i did see the "less ram hungry" thought that may actually be part of the issue - not keeping things that benefited from that persistence around long enough. Traded throughput away for smaller lookup tables. As for "medieval technology" in what way? If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward?
- pron 5y ago
  > Traded throughput away for smaller lookup tables. Much of the improvement came from a re-encoding of String (no longer internally encoded as UTF-16), and more sophisticated GC algorithms. > If the jvm cant run a day without creating a hcrash report and you need 10 times as many cpus to complete a job in the same time, how is that a step forward? If you see crashes, submit a bug report, but we've not been seeing any increase in crash reports. It's possible that you're using a library that hacks into JDK internals and is a cause of such problems. Try using JDK 16 or 17, where strong encapsulation is turned on (at least by default).
  - DarkmSparks 5y ago
    Those crashes were just on our unit tests, creating linking and destroying large volumes of objects, throwing them in a thread for some basic compute then writing results to disk. I agree its really about the gc, but the new ones just never seemed to beat the setup we have on 8, and there is only so much time that can be devoted to making things that work, work on "new shiney". java after 8 is just mayhem, before it was easy, oracle for some things, ibm for others. now there are new long term releases faster than we can test them, they fail at least one of the unit tests that all pass on 8, and openjdk is missing half the really nice stuff that was once free. >submit a bug report but to who and under what title? Oracle, IBM, openjdk? e.g. "none of the corba stuff works anymore because its not part of 'new java'" is whose fault?

ashtonkem 5y ago

Must be something unique in your workload. For my team, later versions of Java have been stable and a bit faster than older versions.

krzyk 5y ago

jdk 8 is not rock solid nor performant. You should look at your codebase, you might be doing some strange things that changed in newer JDKs (e. g. String split no longer uses the sour String, but I don't remember when they changed that). Some options were deprecated because they are also always on (not all probably).

DarkmSparks 5y ago
3 years uninterupted uptime and counting. what in 17 do you think is worth risking downtime?
- fridif 5y ago
  Nothing for you, but something for us.
- sigzero 5y ago
  Why would there be downtime? It's faster. Less RAM hungry. Tons of new great features. I mean, if you don't want or feel the need to upgrade then don't. There are plenty of reasons to do so IMO.
  - DarkmSparks 5y ago
    Because the core system dates back to jre... 1.4, has had ~2 decades of painful testing and big chunks of code dont currently work on anything newer than 8. a bug that takes 100 hours to manifest takes multiples of that to fix. compute and ram is crazy cheap these days, developers are not, and finding good ones is harder than ever.
    - stuff4ben 5y ago
      Yeah I'm gonna say you're an edge case and that the majority of users will see performance benefits. Maybe not you, but that's legacy code for ya and an awful lot of technical debt that's likely not worth it.

deleted 5y ago

[deleted]

hyperpape 5y ago

The magnitude of the change should tell you that you're hitting a weird edge case. Obviously new versions of the jre are not going to be 10x slower in general.