[swift-evolution] What about garbage collection?

[Ondrej Barina]

-1
GC does not have performance problems on server side??
Please tell that to my colleges who are spending 50% of their time
analysing and tweaking GC in java after every release of new versions.
It becoming such a pain sometimes, that we are discussing re-writing
some servers from Java to C++ (just to avoid GC issues)
Ondrej B.

On Tue, Feb 9, 2016 at 3:40 PM, Radosław Pietruszewski
<swift-evolution at swift.org> wrote:
> An***id lagged behind iOS for years in smoothness and responsiveness at
> comparable hardware — my understanding is that this is largely because of GC
> pauses.
>
> I love GC. I’d love GC in Swift, too. But it really is a real performance
> problem in _interactive_ applications (much less of an issue for server side
> stuff), on memory-constrained devices.
>
> — Radek
>
> On 09 Feb 2016, at 15:35, Jean-Denis Muys via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> My understanding (from what I’ve seen in the literature, but I am in no way
> an expert) is that RC has worse worse case behaviour than GC regarding
> pauses.
>
> Also arguments regarding RAM use (and perhaps even battery use), as all
> hardware resource-based arguments, have always been proven wrong in the past
> as hardware has evolved to more and better.
>
> The usual argument is RAM is cheap, programmer’s time, especially debugging
> time, is expensive.
>
> I find it interesting that the commonly accepted wisdom is that GC is the
> right thing to do. To quote but one blog post I’ve read:
>
> It’s a long since resolved dispute, and GC won. I don’t want Steve Jobs to
> reach out from the grave and drag us back to the 70s. There’s nothing
> special about mobile phones: they are more powerful than the computers that
> GC won on in the first place.
>
>
> So I’d be interested in understanding why we are about alone on our Apple
> island with our opinion that RC is better than GC? Are they all collectively
> wrong in the rest of the universe? (not that I condone argument from
> majority)
>
> I can only state that my experience with GC has been with mostly with
> Macintosh Common Lisp a rather long time ago, and I did really love it.
>
> So for me, GC would be a +1, but not a very strong one, as I find RC
> adequate.
>
> Jean-Denis
>
>
>
> On 09 Feb 2016, at 07:01, Colin Cornaby via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> I thought I’d add my opinion to this thread even though it’s been well
> covered in different posts, just to put more weight on the -1 argument…
>
> I spend most my time dealing with performance sensitive code, and Swift’s
> predictability is a very strong pro for it against languages like Java.
> Java’s garbage collector provides too much uncertainty and instability to
> performance.
>
> There certainly are tradeoffs. ARC won’t catch things like circular retain
> loops. But as mentioned, tagged pointers on the modern architecture take
> care of the retain/release overhead.
>
> I’ll put it a different way that sums up why I felt the need to reply: ARC
> has it’s inconveniences, but moving to garbage collection would likely lead
> us to abandon any plans to adopt Swift for many of our performance sensitive
> projects. If someone solves the “pausing” problem in a garbage collected
> language I’d reconsider. But until then it would take Swift out of
> consideration for a lot of projects.
>
> On Feb 8, 2016, at 11:56 AM, Félix Cloutier via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> Has there been a garbage collection thread so far? I understand that
> reference counting vs. garbage collection can be a heated debate, but it
> might be relevant to have it.
>
> It seems to me that the two principal upsides of reference counting are that
> destruction is (essentially) deterministic and performance is more easily
> predicted. However, it comes with many downsides:
>
> object references are expensive to update
> object references cannot be atomically updated
> heap fragmentation
> the closure capture syntax uses up an unreasonable amount of mindshare just
> because of [weak self]
>
>
> Since Swift doesn't expose memory management operations outside of
> `autoreleasepool`, it seems to me that you could just drop in a garbage
> collector instead of reference counting and it would work (for most
> purposes).
>
> Has a GC been considered at all?
>
> Félix
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>