Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift at Apple: Migrating the Password Monitoring Service from Java

swift.org

Post reply on HN
Print view View original

131–140 of 235 posts

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#131

Post by cellularmitosis »

javanonymous wrote: post #93
tiffanyh wrote: post #8

Earlier quoted context omitted.

I'd typically agree with your comment but ... Given that they also experienced a 90% reduction in Memory Usage (presumably from Java GC vs Swift AOT memory management) - it seems more likely the gains are in fact from the difference in languages.

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

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#133

Post by DavidPiper »

quux wrote: post #2

I'm hoping to hear some good news at WWDC for swift development in editors other than Xcode (VSCode, Neovim, etc.) Last year they said "we need to meet backend developers where they are" and announced plans to improve sourcekit-lsp and other efforts.

Swift SourceKit LSP + VSCode is actually pretty good these days. I recently got it working with CMake for a Swift / CMake project, and the only real pain in that was getting CMake set up properly. Everything else worked out of the box with VSCode's extension manager.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#134

Post by dagmx »

dgs_sgd wrote: post #118
mpweiher wrote: post #111

Earlier quoted context omitted.

With the 90% reduction in memory consumption, I'd wager that most if not all the performance improvement came from that. In fact, it is a little surprising that hardware utilization only dropped 50%. Reduced memory consumption for cloud applications was apparently also the primary reason IBM was interested in Swift for a while. Most cloud applications apparently sit mostly idle most of the time, so the number of clie…

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?

Swift is at a good middle ground of performance, safety and ease of use.

It has higher level ergonomics that something like rust lacks (as much as I like rust myself), doesn’t have many of the pitfalls of Go (error handling is much better for example) and is relatively easy to pickup. It’s also in the same ballpark performance as rust or C++.

It’s not perfect by any means, it has several issues but it’s quickly becoming my preferred language as well for knocking out projects.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#135

Post by sweetjuly »

cogman10 wrote: post #117
mrighele wrote: post #82

Earlier quoted context omitted.

The 90% reduction doesn't necessarily have to be related only to GC. In my experience Java is a memory hog even compared to other garbage collected languages (that's my main gripe about the language). I think a good part of the reason is that if you exclude primitive types, almost everything in Java is an heap-allocated object and Java objects are fairly "fat": every single instance has an header of between 96 and 12…

The java GC approach is somewhat unique compared to other languages. There are multiple GCs and pretty much all of them are moving collectors. That means the JVM fairly rarely ends up freeing memory that it's claimed. A big spike will mean that it holds onto the spike's amount of memory. Many other GCed languages, such as swift, CPython, Go, do not use a moving collector. Instead, they allocate and pin memory and fre…

> Many other GCed languages, such as swift

Swift is not garbage collected, it uses reference counting. So, memory there is freed immediately when it is no longer in scope.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#136

Post by vips7L »

sweetjuly wrote: post #135
cogman10 wrote: post #117

Earlier quoted context omitted.

The java GC approach is somewhat unique compared to other languages. There are multiple GCs and pretty much all of them are moving collectors. That means the JVM fairly rarely ends up freeing memory that it's claimed. A big spike will mean that it holds onto the spike's amount of memory. Many other GCed languages, such as swift, CPython, Go, do not use a moving collector. Instead, they allocate and pin memory and fre…

> Many other GCed languages, such as swift Swift is not garbage collected, it uses reference counting. So, memory there is freed immediately when it is no longer in scope.

Reference counting is a form of garbage collection.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#137

Post by cogman10 »

cellularmitosis wrote: post #131
javanonymous wrote: post #93

Earlier quoted context omitted.

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

If it were such an easy problem to fix, don’t you think they would have done so rather than rewriting in Swift?

Having been in development for a long time, no.

Frankly, it just takes some motivated senior devs and the tantalizing ability to put out the OP blog post and you've got something management will sign off on. Bonus points you get to talk about how amazing it was to use Apple tech to get the job done.

I don't think they seriously approached this because the article only mentioned tuning G1GC. The fact is, they should have been talking about ZGC, AppCDS, and probably Graal if pause times and startup times were really that big a problem for them. Heck, even CRaC should have been mentioned.

It is not hard to get a JVM to startup in sub second time. Here's one framework where that's literally the glossy print on the front page. [1]

[1] https://quarkus.io/

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#138

Post by quux »

rafram wrote: post #84
klausa wrote: post #26

Earlier quoted context omitted.

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.

> Safari-on-Windows level of shenanigans of reimplementing AppKit on other platforms I was curious about this, so I downloaded it to take a look. It doesn't look like they actually shipped AppKit, at least as a separate DLL, but they did ship DLLs for Foundation, Core Graphics, and a few other core macOS frameworks.

Yep they did. I think those dlls are have their origin in NeXT’s Openstep for Windows product, which let you develop windows apps using the NeXT APIs.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#139

Post by conradev »

mpweiher wrote: post #111
paxys wrote: post #5

> In comparison with the previous Java service, the updated backend delivers a 40% increase in performance, along with improved scalability, security, and availability. As is always the case with such rewrites, the big question is whether the improvements came from the choice of language or because they updated a crusty legacy codebase and fixed bugs/bottlenecks.

With the 90% reduction in memory consumption, I'd wager that most if not all the performance improvement came from that. In fact, it is a little surprising that hardware utilization only dropped 50%. Reduced memory consumption for cloud applications was apparently also the primary reason IBM was interested in Swift for a while. Most cloud applications apparently sit mostly idle most of the time, so the number of clie…

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.

Re: Swift at Apple: Migrating the Password Monitoring Service from Java

#140

Post by cogman10 »

username223 wrote: post #129
cogman10 wrote: post #119

Earlier quoted context omitted.

It all depends, but one major advantage of the way the JVM GCs is related memory will tend to be colocated. This is particularly true of the serial, parallel, and G1GC collectors. Let's say you have an object that looks like A -> B -> C. Even if the allocation of A/B/C happened at very temporally different times and inbetween different allocations, the next time the GC runs as it traverses the graph it will see and p…

That's the theory -- a compacting collector will reduce fragmentation and can put linked objects next to each other. On the other hand, a reference count lives in the object, so you're likely using that cache line already when you change it. I don't know which of these is more important on a modern machine, and it probably depends upon the workload.

The problem is memory colocation not RC management. But I agree, it'll likely be workload dependent. One major positive aspect of RC is the execution costs are very predictable. There's little external state which can negatively impact performance (like the GC currently running).

The downside is fragmentation and the CPU time required for memory management. If you have an A -> B -> C chain where A is the only owner of the B and B is the only owner of C, then when A hits 0, it has to do 2 pointer hops to deallocate B and then deallocate C (plus arena management for the deallocs).

One of the big benefits of JVM moving style collectors is that when A dies, the collector does not need to visit B or C to deallocate them. The collector only visits and moves live memory.

Post reply on HN