7 ms·

Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed. If you run a bunch of different microservices with distinct allocati

by leapis 3y ago

Depends- one of the hardest parts of the 11-20 upgrade for us was that cms gc was removed. If you run a bunch of different microservices with distinct allocation profiles, all with high allocation pressure and performance constraints, and you've accomplished this w/ the help of a very fine-tuned CMS setup, migrating that over to G1/ZGC is non-trivial

hmottestad 3y ago
Is that what happened at your company?
- leapis 3y ago
  Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.
  - kaba0 3y ago
    Isn't the default config correct for pretty much all workloads, unless you have very special requirements? Like, at most one should just change the target max pause time in case of G1, depending on whether they prefer better throughput at the price of worse latency, or the reverse.
xxs 3y ago
Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost. High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.
- threeseed 3y ago
  If you GraalVM Native Image or one of the frameworks based on it then bootstrap cost disappears: https://quarkus.io https://quarkus.io
  - wice 3y ago
    GraalVm is great, it made our Spring REST API app go from 10+ seconds to 0.5 seconds on startup (not to mention the lower mem and cpu requirements). Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182 https://github.com/oracle/graal/issues/7182
bberrry 3y ago
I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.

by leapis 3y ago

hmottestad 3y ago

Is that what happened at your company?

leapis 3y ago
Yup. We've clearly benefitted- G1 and generational ZGC have large advantages over CMS- but it's a lot of experimentation and trial-and-error to get there, whereas other deprecations/removals are usually easier to resolve.
- kaba0 3y ago
  Isn't the default config correct for pretty much all workloads, unless you have very special requirements? Like, at most one should just change the target max pause time in case of G1, depending on whether they prefer better throughput at the price of worse latency, or the reverse.

xxs 3y ago

Java sort of suck for microservices (microservices suck on their own) as it has relatively high bootstrap cost. High allocation rate feels weird with micro services - I suppose that depends a lot on the coding style. G1GC is meant for generally large setups, with several cores at least. E.g. the default setup of 2048 areas on 2GB heap means, allocations over 1MB require special care.

threeseed 3y ago
If you GraalVM Native Image or one of the frameworks based on it then bootstrap cost disappears: https://quarkus.io https://quarkus.io
- wice 3y ago
  GraalVm is great, it made our Spring REST API app go from 10+ seconds to 0.5 seconds on startup (not to mention the lower mem and cpu requirements). Except… when we try to build it with Jenkins on a Kubernetes cluster, this happens: https://github.com/oracle/graal/issues/7182 https://github.com/oracle/graal/issues/7182

bberrry 3y ago

I can't help but think if you're teetering on a knife's edge, only holding on thanks to hyper tuned GC params, then you should take a step back and consider getting out of that predicament.