nickyvdicarlo

For what it's worth, JP Morgan specifically is probably the best positioned of all the major banks to endure any political and/or economic instability that might arise in the near-ish future. Not that this should necessarily drive your decision on who to bank with, but having spent the last decade or so working at various large US banks I have a lot of respect for the way JPMC operates

- The vast majority of their infra (at least as of ~3 years ago) is self-hosted in data centers that they own, and a lot of their other key cloud infra is/was multi-cloud (i.e. operations could fail over to GCP in the event of an AWS outage)

- Financially they have the healthiest balance sheet of any non-state-owned bank (like, in the entire world). Over the last ~20 years JPMC has acted as a sort of lender of last resort several times, most recently when they bought out First Republic.

- Politically, after navigating the aforementioned instability Jamie Dimon has almost carte blanche support from the shareholders, and everyone knows it. As a result, he can afford to be a lot less... compliant with the current US regime than other major players have been recently.

I was working on optimizing a UUID scanner recently, and was baffled when I discovered that Java represents all char primitives in UTF-16, regardless of the original encoding.

So even given an ascii String, if you want to do something like

char c = input.charAt(index)

the JVM is going to jump to that index, check whether the character at that index isLatin(), then cast that single byte into to a 2 byte char... every single time.

in the naive solution, omething like 15% of the CPU cycles were spent checking isLatin() over and over again

Yeah, I'm sure people do it, but I'm having a hard time picturing why...

I would be very surprised if ZGC became the default, because it incurs a significant overhead penalty to eliminate those GC pauses. All else equal you're effectively just sacrificing throughput for latency, since it's doing a bunch of extra housekeeping in the background (foreshadowing...) That's a perfectly reasonable tradeoff to make if low latency is a priority (or perhaps more importantly if having very consisent/predictable latency is a priority) but in most Java projects I've been exposed to that's been a tertiary concern at best. Frankly, I question if most Java developers are even aware that they're allocating physical memory when they type 'new'...

In the modern enterprise Java world (that I've been exposed to) it's very common to have a mandate that all components deploy a minimum of N instances across X regions for resiliency. By design that almost always means you're deploying at least 2x more compute than you strictly need, so the top priority is generally minimizing per-instance overhead to minimize cloud spend.

For example, the default templates at my current company deploy something like 0.25-0.5 vCPU per instance, and therin lies the rub. ZGC performance is _catastrophically_ bad with <=1 cpus because when there's only one core, any "concurrent" GC events become full on stop the world events. We had someone pilot a change to the default JVM args for all components because they heard that ZGC would reduce latency, only to discover that basically all of our microservices immediately failed their perf tests. For the first one I spot checked, throughput was down ~90% and p95 went from ~40ms to >1s, because more time was being spent on "background" GC than actually servicing requests.

Hope that didn't come off adversarial. I just find GC fascinating, and ended up spending a bunch of time working with the team that owns those defaults to draft general recommendations. TLDR is that when in doubt don't specify/let the JVM pick for you, and don't be surprised if it picks serial :)