Greetings,
With JavaOne in Las Vegas, last month was epically busy! It was great to
finally have the ability to meet and discuss the Quality Outreach
program with some of you... face-to-face!
This installment of the newsletter is packed as we have several
heads-ups, including new Early-Acces
Since there was not major pushback, ill see this as green line for JIRA, ill
file later today
> On Nov 8, 2022, at 9:46 AM, David Capwell wrote:
>
> Thanks all for the replies, I hope I am posting a summary of all the feedback
>
> 1) double check with legal due to LGPL
> 2) need way to opt-out
Any objections to making these changes, at the very last minute, for
4.1-rc1 ?
This is CASSANDRA-12029 and CASSANDRA-7486
Provided we figure out patches for them in the next day or two.
CMS was deprecated in JDK 9, I don't see a good reason to follow it
until it's dying breath, and we already have G1 ready in the jvm
options files so this should be an easy switch, +1.
Kind Regards,
Brandon
On Wed, Nov 9, 2022 at 1:22 PM Mick Semb Wever wrote:
>
> Any objections to making these
CASSANDRA-12029/CASSANDRA-7486 I am not in favor of doing for 4.1, we spend
time validating the current settings, so changing at the last minute adds risk;
so rather push that to 4.2/5.0
> On Nov 9, 2022, at 11:25 AM, Brandon Williams wrote:
>
> CMS was deprecated in JDK 9, I don't see a good
At DataStax we’ve been shipping those optional G1 settings as the default for
many years now, so I am +1 to at the very least making the change in trunk, but
really I would think it fine to make it back in 4.0 and 4.1 as well.
-Jeremiah
> On Nov 9, 2022, at 1:32 PM, David Capwell wrote:
>
> C
G1 you can argue for with the changes in the JDK, though it's MUCH less
friendly to small heaps (e.g. probably our default simple user).
Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd b
My recollection (and brief sleuthing now) surfaces: we've gone back and forth
on the G1 vs. CMS debate over the years and I think we settled on "it all
depends on your environment, workload, and you need to tune it anyway. It might
be worth having a 'default' mode that selects one of the two bas
If CMS is gone, is there a friendlier alternative to G1?
On Wed, Nov 9, 2022 at 3:53 PM Josh McKenzie wrote:
>
> My recollection (and brief sleuthing now) surfaces: we've gone back and forth
> on the G1 vs. CMS debate over the years and I think we settled on "it all
> depends on your environmen
There's a lot of work that's gone into G1 to the point where for
almost all workloads it will perform better than CMS. However, there
are almost no knobs to tune (most G1 params are "advisory" and G1 will
happily ignore them if it wants to), so there may not be a great
replacement if people are tun
> Can you define "friendlier" in the context of CMS?
Friendlier to small heaps, to Jeff's point about it being much less
friendly to them.
The default garbage collector in Java 11 is G1*. *It's designed to be
self-tuning, so I'd call it friendly. We have run Java 8 and 11 on G1 in
production on all of our 1,000+ clusters for several years.
I'd agree with Jeremiah that it's worth changing in trunk at the very least
and consider back
fwiw, the "CMS is friendlier for small heaps with C*" conclusion may no longer
be accurate; a lot of work has gone into G1 since the last time we've covered
the topic as a project. Nevermind the changes in C*.
Lots of moving targets.
On Wed, Nov 9, 2022, at 6:13 PM, Brad wrote:
> The default ga
>From a user PoV, I'd call G1 drastically friendlier than CMS in that it
tends to be well-behaved under a variety of workloads and heap sizes right
out of the box without the kind of dark-art tuning and overnight surprises
you get with CMS. Granted the smallest heap I have now is 2GB, but that's
n
14 matches
Mail list logo
