Swift at Apple: Migrating the Password Monitoring Service from Java

The thing about DRAM is that it isn't SRAM; cost matters. You struggle to find deployment environments that have less than 1 GB DRAM available per core, because at that point, ~95% the HW cost is typically CPU anyway. Shrinking that further is kind of pointless, so people don't do it. Hence, when utilizing 16 cores, you get at least 16 GB DRAM that comes with it, whether you choose to use it or not. If you use only 10% of that memory by removing the garbage from the heap, then while lower seems better and all that, it's not necessarily any cheaper in actual memory spending, if both fit within the same minimum 1 GB/core shape you can buy anyway. It might just under utilize the memory resources you paid for in a minimum memory per CPU shape, which isn't necessarily a win. Utilizing the memory you bought isn't wasting it.

Each extra GB per core you add to your shape, actually costs something. Hence every GB/core that can be saved results in actual cost savings. But even then, usually every extra GB/core is ~5% of the CPU cost. Hence, even when going from 10 GB/core (sort of a lot) to 1 GB/core, that only translates to ballpark ~50% less HW cost. Since they did not mention how many cores these instances have, it's hard to know what GB/core were used before and after, and hence whether there were any real cost savings in memory at all, and if so what the relative memory cost savings might have been compared to CPU cost.

This is why serverless is taking off on the opposite end of the spectrum (and why it’s so cheap)

You can share memory not only at the machine level, but between different applications.

Interesting. If IBM was trying to solve for memory consumption, why do you think they picked Swift over alternatives that might also have achieved lower memory consumption?

IBM is a huge and quite balkanized company and I don't think there was ever a centralized push towards Swift outside some excited parties. With that, I would note that circa 2018 there was a DRAM shortage in the industry and people started thinking more about memory conservation in datacenter workloads.

The JVM tends to use as much memory as it can for performance reasons. It is not a reliable indicator of how much memory it actually needs. Why spend resources on clearing memory if there's still unused memory left?

If memory is an issue, you can set a limit and the JVM will probably still work fine

The typical rule of thumb is that getting good performance out of tracing GC requires doubling your memory usage, so a 90% reduction suggests that they made significant improvements on top of the language switch.

The java runtime is a beast. Even the fact that another runtime is just capable to do a similar thing is impressive, disregard the fact that it might be better. Even being on par makes it interesting for me to maybe try it on my own.

You can learn a lot when writing V2 of a thing though. You've got lots of real world experience about what worked and what didn't work with the previous design, so lots of opportunity for making data structures that suit the problem more closely and so forth.

But did they write the backend from scratch or was it based on a number of “com.apple.libs.backend-core…” that tend to bring in repeating logic and facilities they have in all their servers? Or was it a PoC they promoted to MVP and now they’re taking time to rewrite “properly” with support for whatever features are coming next?

As a C# dev, I guess I've just taken it for granted that we have value types. Learned something new today (that Java apparently does not).

However you can make use of Panama to work around that, even if it isn't the best experience in the world.

Create C like structs, in regards to memory layout segments, and access them via the Panama APIs.

I would have guessed it's boxed primitives.

For others that hadn’t head of CADT either: https://www.jwz.org/doc/cadt.html

I confess to having been part of the cascade at various parts of my career.

  If the "just rewrite it and it'll be better" people were as right as they often seem to believe

I suspect that didn’t fit into the goal of the blog post.

I don’t think it’s meant to be a postmortem on figuring out what was going on and a solution, but more a mini white paper to point out Swift can be used on the server and has some nice benefits there.

So the exact problems with the Java implementation don’t matter past “it’s heavy and slow to start up, even though it does a good job”.

Go is similar to Swift when it comes to mandatory costly abstractions.

It’s only Rust (or C++, but unsafe) that have mostly zero-cost abstractions.

Xcode is probably like, one of the top… 3? 5? biggest macOS-native applications in the world.

Making it cross-platform would require either reimplementing it from scratch, or doing a Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms.

There would be no point in doing that. All the devs they care about already have Macs. If you are on Windows or Linux and you want to work on Swift server side code then you can use their official LSP or VSCode extension in your favorite editor.

Who even wants Xcode to be cross platform? People can barely tolerate it on macs.

What you really mean is people want the iOS development toolchain to be cross platform, and that would mean porting iOS to run in a hypervisor on linux/windows (to get the simulator to work). That is way too big a lift to make sense.

Swift has an official LSP: https://github.com/swiftlang/sourcekit-lsp

It was first released 7 years ago.

Especially since the request contains the user's (hashed) passwords. You definitely don't want to be holding that on the server for longer than necessary.

Is it really a problem? Client can pass an encryption key with the request and then collect encrypted result later. As long as computation is done and result is encrypted, server can forget the key, so cache is no longer a privacy concern.

thanks!

Ok, I'm pretty skeptical that they actually did optimize what they could. In fact, reading between the lines it sounds like they barely tried at all.

For example, they mention G1GC as being better than what was originally there but not good enough. Yet the problems they mention, prolonged GC pauses, indicates that G1GC was not the right collector for them. Instead, they should have been using ZGC.

The call out of G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11?

And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal?

The only mention they have is the garbage collector, which is simply just one aspect of the JVM.

And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21.

I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.

> TFA makes it clear that they first optimized the Java version as much as it could be under Java's GC

No, it doesn’t.

Will Rust really be better than Swift in such a context? Doesn’t that more or less depend on what kind of memory management is being used in Rust?

No, I was making a point about if the goal is lowering resource usage, more throughput, concurrency, speed/perf, etc, a larger company can achieve that "unfair advantage" of things like rust or elixir etc because they have the resources as compared to SMBs or startups.

Of course, every company and org has to see whats best and feasible for them. Valid points you brought up no doubt.

> I don't see any reason to evaluate Go at all.

https://devblogs.microsoft.com/typescript/typescript-native-...

and it's dead

There was really big excitement about Swift everywhere, but Apple decided not to capitalize on it and hype died off. Swift is pretty much Mac/iOS language and there are no indications that it is going to change anytime soon.

Rust and Swift share a lot of core concepts.

Swift has a few extra bits for Objective-C compatibility (when running on Apple platforms), but otherwise the biggest differences come to design and ergonomics of the language itself.

If I need complete control over memory for say a web server, or am writing code to run on an embedded device (e.g. without Linux), I'll use Rust - even if Swift technically has the features to meet my needs.

Thats the reverse if I am creating mobile or desktop apps. I'd probably prefer using neither for web services like in this article, but would still probably pick Swift given a limited choice.

I really like it. It feels clean to me and easy to read, but has great async and other modern features. A bit like a compiled TypeScript without all the baggage that comes from JS’s existence.

It has its issues in places, mostly the compiler, but I love getting to develop in it.

I suspect you hear less about it because it’s no longer new and the open source community doesn’t seem to care about it that much, unlike Rust.

It still seems to be viewed as “the iOS language” even though it can do more than that and is available on other platforms.

Fine language for anyone on Apple's ecosystem.

If one rather be OS agnostic, then not so much.

As for HN, I see comments about swift becoming complex and bloated with many ways to do the same thing. Like C++ish.

Not quite the same but close. I assume OP was mentioning from one stack into a completely different one.

Swift has all of that already answered. Non Xcode swift with SwiftPM is solid