11 ms·

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

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?
  - crummy 5y ago
    > now there are new long term releases faster than we can test them Aren't they every 2-3 years?
    - DarkmSparks 5y ago
      now yes. fixing what isnt broken isnt high on the list of things to do.
      - rualca 5y ago
        > fixing what isnt broken isnt high on the list of things to do. It's hardly reasonable to try to pin the blame of not wanting to maintain software as a stability issue with a newer LTS release of the JDK. It's perfectly fine if you make the call to stick with JDK8 forever, but that's a personal call.
    - quantified 5y ago
      They’re pretty well spaced out.
      - DarkmSparks 5y ago
        used to be. java 6 (previously widely deployed jvm) was 2006 java 8 (current widely deployed jvm) was 2014 now, 7 years later, we are on java 17 and the most significant thing to change is to break most everything that worked in 2014, and promotional material dare not mention java 8... In fact "widely deployed" doesnt cut it for java 6, pretty much every pc, windows linux and mac had a solid java 6 deployment. java 17 has a lot to live up to.
  - sandGorgon 5y ago
    this is super interesting. Honestly, I do think that your testcase is worth replicating. I dont think anyone is advocating you tradeoff stability for shiny features, but i think everyone is existing in a state of disbelief that Java 17 would break on your usecase. But if what you're saying is true... it super duper worth it for everyone to submit that test suite. Java 17 is also LTS ...so that effort would be worth it in the long term.

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?
- crummy 5y ago
  > now there are new long term releases faster than we can test them Aren't they every 2-3 years?
  - DarkmSparks 5y ago
    now yes. fixing what isnt broken isnt high on the list of things to do.
    - rualca 5y ago
      > fixing what isnt broken isnt high on the list of things to do. It's hardly reasonable to try to pin the blame of not wanting to maintain software as a stability issue with a newer LTS release of the JDK. It's perfectly fine if you make the call to stick with JDK8 forever, but that's a personal call.
  - quantified 5y ago
    They’re pretty well spaced out.
    - DarkmSparks 5y ago
      used to be. java 6 (previously widely deployed jvm) was 2006 java 8 (current widely deployed jvm) was 2014 now, 7 years later, we are on java 17 and the most significant thing to change is to break most everything that worked in 2014, and promotional material dare not mention java 8... In fact "widely deployed" doesnt cut it for java 6, pretty much every pc, windows linux and mac had a solid java 6 deployment. java 17 has a lot to live up to.
- sandGorgon 5y ago
  this is super interesting. Honestly, I do think that your testcase is worth replicating. I dont think anyone is advocating you tradeoff stability for shiny features, but i think everyone is existing in a state of disbelief that Java 17 would break on your usecase. But if what you're saying is true... it super duper worth it for everyone to submit that test suite. Java 17 is also LTS ...so that effort would be worth it in the long term.