Hacker News Reader

Comment by ncmncm | Hacker News Reader

Thanks, I still prefer exactly-zero ms pauses. Maybe that's just me, but I don't think so. And, I don't think I am giving anything up by skipping them.

View on HN

Exactly zero pauses only exist if you never free memory, which for most purposes is not an option. In most languages, freeing all all the heap-allocated objects of a big array will take longer than in a language with GC. The reason pauses tend to be bigger in a GCed language is because all the freeing is being done at once, instead of every single time an object is determined to no longer be needed.

In any case, the tradeoff you're making is that you have deal with memory. Even in a language like Rust, you need to care about references, ownership, struct vs heap and possibly even reference counting. You might even be bitten by "running out of memory" due to memory defragmentation.

In most cases, you don't need to care about these things in a GC'ed language, at the expense of larger memory usage and possibly noticable pauses.

Of course, certain applications do indeed never allocate once they have started up.

Indeed, that is a very common practice, where latency matters. You might have a great deal of memory heap activity in the first second, and then hardly any for months after.

> In most cases, you don't need to care about these things in a GC'ed language, at the expense of larger memory usage and possibly noticable pauses.

GC has other drawbacks as well. The whole tracing workload (which still exists even in low-latency, concurrent GC's) messes up your locality of references and interacts badly with CPU- and OS-level caching and memory management. Plus the mutator part of your program is heavily constrained in how it can layout objects in memory, since the tracing GC must be enabled to select references to other objects unambiguously. It's a non-trivial drain on performance on memory-bandwidth limited workloads, which tends to be most of them these days.

Reference counting does away with most of these issues, and gives you deterministic finalization of all resources not just memory. Alternately, you can selectively use arenas to defer the freeing of some objects, while still being deterministic elsewhere.

zozbot has it right.

Reference counting is a form of GC to use when performance doesn't matter. Performance never matters except where it does. But automated memory management without reference counting is usual practice in a modern non-GC language.

Freeing an array of objects only involves a series of calls to a deallocator when the array elements have pointers in them. That is typically unavoidable in Java, but not in non-GC languages.

Arena allocation, where memory in a subsystem is allocated using a specific allocator object, deallocation there is an in-line no-op, and all of subsystem memory is reclaimed en bloc at a chosen event boundary, is a common alternative where more control is needed. It is still not "manual memory management"; memory for objects is managed invisibly, and still without reference counting.

The usual advertising for GC is that it means you don't need to think about managing memory. The actual experience is that, where it matters at all, you have to think about it a great deal more.

> In most languages, freeing all all the heap-allocated objects of a big array will take longer than in a language with GC.

Only if elements of the array are separately allocated (boxed) or have destructors.

And if the array is heap allocated.

If the array is stack-allocated and the elements are boxed (i.e. heap-allocated) or have destructors, you are still going to need to call the destructors or the free on the elements when the array goes out of scope.

Such a layout, and all it costs, is typically unavoidable in GC languages, and usually easily avoided in non-GC languages, particularly in cases where it would matter.

Thus, it is incorrect to talk about multiple calls to a deallocator. You get just one for the whole array.

My point was: it still takes longer time to de-allocate a large array even if the only thing that needs to be freed is the array itself, when compared to a GC. GC never needs to free anything, it instead overwrites garbage memory with live memory.

I can write (and am in fact developing right now) a music app in a non-GC language, with a real-time audio thread which (unless faced with unusual inputs like hundreds of simultaneous events) performs zero allocations or deallocations after initial startup. It acquires and releases all heap allocations from a wait-free queue between the audio thread and GUI thread.

If I were to port the app to C#, I have no way of telling the C# GC to never pause the audio thread, and to only pause the GUI thread. I'm not sure if it's possible for a tracing GC to coexist with a never-paused thread which owns manually memory-managed types, and for the two threads to exchange manually freed or GC'd objects without FFI boilerplate, serialization, or copying. If it exists (and there's a GUI framework written in the GC portion of the language), let me know!

Admittedly manual memory management does mean a lot more things to worry about (ranging from manual memory management to lock-free wait-free programming) Personally I find deterministic lifetimes and single ownership which can be moved/swapped to be elegant. However, Qt's QObject system combines the practical disadvantages of manual freeing (having to track complex semantics in your head, and check whether each method call transfers ownership or not, with leaks or use-after-free if you get it wrong) with the inelegance of GC (pervasive aliasing and mutability, unclear ownership, a magical runtime-like system).

Sure, and in your specific use case, the tradeoff of dealing with memory seems worth it.

My point was that there are tradeoffs, which you admit. The comment i responded to indicated that there wasn’t one.

I agree that your specific use-case is indeed good reason for manually managed memory, but theoretically, I don’t see anything inherent in specifying GC on a per-thread basis. Like, perhaps one could set a property on a new Thread object and set GC to false - that would probably allow your program to function even in a managed environment.

Not using GC does not, in fact, imply "manually managed memory". Manually managed memory is the only thing possible in C, but C is not the only non-GC language. The most commonly used non-GC languages provide other mechanisms, and usual practice in them is to rely on their non-GC, automated memory management.

Do you mean RAII and rust’s ownership model? It still has very similar tradeoffs to manual memory management, they are just much less error prone.

But the fundamental thing is that you still have to think about memory, memory layout will have to be considered during refactors, etc.

If you are not thinking about memory, or memory layout, you are not programming. Anyway, not programming well.

And "tradeoffs" is a misleading term to apply to a process that does not involve giving up anything in exchange for the benefit of pause-free, fully predictable operation.

There are different levels of “thinking about memory”. The distinction between low and high level languages is not arbitrary. In a CRUD app, you don’t want memory layout to be the center of attention, a major refactor in abstraction should not really require a re-thought on the life time of objects, etc.

And you do absolutely give up something with not using a GC: speed of development, much bigger teams can work on the project at the same time while not stepping as much on each other’s foot, etc. It’s not an accident that perhaps the majority of all software development is in managed languages, where it is not absolutely crucial to control the exact memory layout.

> "you do absolutely give up ... speed of development"

That is the advertising claim, not substantiated.

A more plausible explanation for "the majority ... in managed languages" is: it enables employing lower-skilled, thus more easily obtained, labor. It doesn't so much matter how fast development is. Such practices commonly split a simple job among five or more people (a "team") who, collectively, probably cost more than one more-skilled employee who could do it all in much less time, but who is hard to attract to do it at all, and anyway better used elsewhere.

If it were 50-50 or so, I would be open to this explanation. But it is an overwhelming majority, making the claim not only substantiated, but empirically proved.

And frankly, you are not getting ahead with your arbitrary gatekeeping on “who is a real programmer”.

I used to work in a C/C++ embedded shop, and I work now at a place where only GCed languages are used.

The statement about enabling lower-skilled employers to be hired is pretty much false. Embedded development payed significantly less than most places that uses Java today (at least in Norway), and there's really no difference in the skill of the people I work with.

There's a _significant_ difference in the problem being solved though. The project I'm working at now is, code-wise, bigger by an order of magnitude. As is the problem domain (ticket-selling services, vs firmware of payment terminal in old job).

When doing embedded, I never had to care about racing conditions in threads or across several microservices. The embedded device was single-core anyways, and only talked to one server.

Dealing with memory has been replaced by handling concurrency. Of those I'd argue that the latter is significantly harder than the first. But both add to development time, as it becomes a core point in most design discussions.

In our case, we truly do not need to care about memory. If we run out of it, we either upgrade the instance or add another instance. The monthly hardware cost is lower than the hourly cost of a developer, anyways. Having one less thing to worry about decreases developer time, as there's one less thing to include in our designs, and one less thing to worry about going wrong.

Erlang is a good example of a per “thread” GC (erlangs unit of concurrency is the process). When one GC triggers, it doesn’t pause the rest of the program.

Not sure if you can disable the GC entirely, but you can set the initial heap high enough that it won’t trigger for the lifetime of the process.

This strikes me a somewhat narrow view of the world. Using a GC is an engineering trade-off like any other.

Taking a dogmatic view on an engineering trade-off isn't good engineering, and closes you off from exploring other, potentially better, ways of solving the problems you actually care about. (Which probably have nothing to do with the details of memory management)

Something tells me you wouldn't say "I prefer exactly no borrow checker [in Rust], and I don't think I'm giving anything up by skipping them".

Wrong on both counts.

> Wrong on both counts. "Tradeoff" implies giving something up, and I just said I hadn't. And, I am happy to abjure the borrow checker; it doesn't solve any problem I have. Either.

(Comment was edited while I was writing a response, original comment I responded to above)

I'm glad to hear that you've taken the time to understand how GC work, and the trade-offs that languages make when use them.

I would be curious to learn more about what you're research as has shown with regards to using a GC in your problem space. It's always interesting to learn about areas of engineering that unique requirements.

If you don't use a GC then you're either using reference counting or manual memory management. Those have their own costs. With RAII popping stack frames means freeing resources recursively. If your free() implementation takes a lock then that can block other threads too, for an arbitrary time if the object graph being released is large.

A garbage collector can do that work concurrently.

Not using GC. Not using reference counting. Not using "manual memory management".

Yeah, right.

CppCon 2016: Herb Sutter “Leak-Freedom in C++... By Default.”

https://www.youtube.com/watch?v=JfmTagWcqoE

Better making use of the best practices advised by Herb, otherwise those destructors are going to surprise you.

It'll surprise him anyway, eventually. After all--humans aren't perfect programmers.

It has been more than thirty years since a destructor surprised me. Herb was unlikely to have been programming at that time.

So what are your credentials in the C++ community to top those from Herb Sutter?

Been on ISO C++ Standard committee for much longer than Herb? But I have no disagreements with Herb.

And authored impactful C++ books and ISO C++ papers such as?

I have no need to "top" Herb. He says nothing inconsistent with anything I have said.

Apparently yes, when you place in doubt his advices,

> It has been more than thirty years since a destructor surprised me. Herb was unlikely to have been programming at that time.

So apparently you have skills that top one of the major C++ community figures.

Being so, the C++ community at large would appreciate those valuable insights.

The only conclusion one can draw is that you are wholly unable to comprehend what you have just read, or aggressively don't care what it says. Either way, enough is enough.

Erm something is managing your memory somewhere, even "the computer explodes before it runs out of memory" methodology used in guided missiles is a form of manual memory management, just a very unusual one.

Same applies to the "program terminates before it runs out of memory" approach.

Yes, something is managing my memory. Just not GC, and not reference counting (which is also GC). As I said.

C++ has destructors, and owning pointers (called "unique_ptr"), and also arena allocators for when those are useful. Rust has its Drop trait and analogs of the other things. (Use of arenas with Rust standard library containers is approaching maturity.) They make memory management automatic and wholly painless. Both languages offer reference-counted GC for places where that is helpful, but such places are rare, and where used typically burn an unmeasurably small fraction of runtime, with no "pauses".

Using destructors just reference counting done the hard way.

> burn an unmeasurably small fraction of runtime

That’s also known as a very short pause.

> With RAII popping stack frames means freeing resources recursively.

Your "GC pause" simply happens on scope-exit.

Except, without the pause.

Oh, those cycles are free? That's not how I remember having to plan compute budgets and deadlines when I worked in real low-latency programming.

When I developed programs in Fortran 77, I did indeed have zero pauses, because all memory was allocated statically at the program start. With any form of dynamic memory, you have effort for managing that dynamic memory and thus pauses. The different technologies only result in those pauses happening at different times and other consequences. Modern GCs at least allow most of the necessary computation to happen in a parallel thread.

And not contributing to the discussion.

At least bring some alternatives to the table or explain what you are doing and why you mean it's so much better..

> With RAII popping stack frames means freeing resources recursively. If your free() implementation takes a lock then that can block other threads too, for an arbitrary time if the object graph being released is large.

For every RAII implementation I've seen, the recursive part is not within the free() implementation; the recursion happens outside the free() (or equivalent) calls, and free() (or equivalent) is called separately for each step, to release the memory for just that step. The time taken by each free() call is independent from the size of the object graph being released.

> I don't think I am giving anything up by skipping them

My understanding is that there are some lock-free algorithms that we do not know how to write without garbage collection [Keir, 2004], so you strictly are giving things up, because you can't use those algorithms.

(But I'm not completely up to date on latest lock-free work.)

I optimize these days mostly by deleting lock-free apparatus.

You don't see any benefits to garbage collection at all? Would you even prefer to do your own memory management if you had a magic GC which never paused? I'd be interested in your reasoning if so.

I'm perfectly happy to have all you lot depending on GC.

And, I don't "do my own memory management". I just don't rely on a GC to do it.

It may be constructive to say what you do do, instead of leaving us to guess and telling us we're wrong.

I mostly use "}".

You write programs so short and uncomplex that you rarely need to free memory?

Ever heard of RAII?

That's still memory management, because you need to worry about lifetimes.

You only need to worry that data that you need doesn't go out of scope.

It is automated, not manual, memory management. Just not GC.

I interpret it as meaning they don't use dynamic memory allocation.

False. Use of dynamic memory allocation without GC, without reference-counting (which is GC) and without manual memory management is the usual practice in C++ and Rust.

Reference-counting GC is available when it is not too costly, which is common, and more convenient, which is rare. Ordinary automatically-generated destructors handle almost everything, almost all the time. Once in a great while, performance demands a concession such as an arena allocator, which also is not "manual memory management", and also not GC, and is radically cheaper than either one.

Memory isn't the only limited resource which needs to be managed. File handles, network ports, etc. all all need proper design to avoid leaks. If you are used to only the allocation and never the cleanup, your design style won't hand effective management of these other types of resources for which GC isn't an option.

I'd use Java if it let me annotate when I want things to be deleted.

... and, generally, if you have to insist on falsehoods to make the case for depending on your GC, you haven't, in the end, made a case at all.

It is a fact that the majority of programming in modern non-GC languages, such as C++ and Rust, involves no manual memory management, no GC, and no reference counting (which is also GC). The memory-management automation provided by the core language and the standard library are equal to almost all challenges, all by themselves.

Thus, users of modern non-GC languages do not experience the pauses seen in GC languages, or the unavoidable pointer chasing, or the cache poisoning, or the "reachable leaks" that are GC languages' dirty secret. They are not, in fact, obliged to "trade off" anything at all for being free of those failings.

That is not to say that all design goals are easy to achieve, but overcoming a GC's failings is is not among the activities needed achieve them.

"Manual memory management" means more than just explicit free(3). If you have to create a destructor, and a class for it to sit in, just to make sure some bit of memory gets freed, that's manual memory management. The falsehoods here are yours.

Self-deception in the terminally confused is always sad to see.

It is extremely rare, nowadays, to "create a destructor" to manage memory. The destructors generated automatically from templates in the Standard Library suffice.

Creating classes is just programming.

So, no, that is not manual memory management.

You're confusing implicit with automatic. That's the best illustration of self-deception and "terminally confused" in this thread. If programmers have to think about when something truly goes out of the last scope it'll be in (sometimes not obvious when it's put into and taken out of containers and passed between callbacks) then it's not automatic. If they have to think about whether they can use/pass a reference and be sure it won't outlive the object itself, it's not automatic. These have been issues in every C++ codebase I've seen, so even if I were personally able to create a codebase without those issues it wouldn't change anything. It also doesn't make a difference if you're so accustomed to a certain set of ownership rules that the time you spend thinking about them is very small. It's still not zero, and other programmers who are less inured to the mess still exist.

It's OK that these issues exist - as you say it's just programming - but don't delude yourself into thinking that's automatic memory management. It's implicit, but it's not automatic and that means it's (at least partly) manual. When you say you don't use manual memory management but then say you let standard-library templates handle it, that's a contradiction and tantamount to a lie.

Repeat that enough, you may come to believe it.

> Thus, users of modern non-GC languages do not experience the pauses seen in GC languages

/doubt

Once you're facing, for example, the deallocation of an entire tree that you own and that's going out of scope, your pause is unbounded. Compared to that, a GC'd language could delay the deallocation, or even in case of stuff like C4 have a dedicated thread deal with it.

Sure, you can always write code in a way that avoids this, but non-consing is also an option for many of the GC'd languages (at least the more advanced ones, like Common Lisp).

GC languages, boxing everything, oblige constructing elaborate linked structures. Boxing is exceptional in non-GC languages, and trivially avoided where latency would matter.

So, doubt all you like, unavoidable random millisecond pauses are not a problem in non-GC languages, no matter how much you wish otherwise.

> Thanks, I still prefer exactly-zero ms pauses.

You're not using caches, then?

If your cache misses are measured in milliseconds, you have a bigger problem than GC pauses.

They just need to have not-exactly-zero ms pauses to violate the requirement above - which they have.

Cache misses are not GC pauses. But GC often causes more cache misses.

Better never call the OS memory manager then.

Also, avoiding GC pauses while still being subject to interrupts and context switches is a common kind of tunnel vision. Non-GC languages are great for systems programming, but if GC wasn't going to be your biggest source of jitter anyway then using one just means more work and/or more bugs.

...not using one...

This is why those of us who make low-latency systems turn off interrupts and context switches.

Not using a GC does not, in fact, make more work or more bugs, given a language that provides resource management facilities, such as C++ and Rust.

Programs using GC do typically leak, and most GCs make leaks much harder to find and fix. Most GCs even make it hard to determine if you have a leak.

I know you think you're a perfect programmer, but the fact is that most programmers aren't. Of the hundreds, possibly thousands, I've worked with, maybe one in twenty could be counted on to write non-trivial code without introducing new object-lifetime issues that every programmer on that project for ever after would have to keep in mind when interacting with that component. Yes, that includes quite a bit of C++ with RAII etc. but also with threads, callbacks, and ill-fated attempts to avoid copies by using references and move semantics. (C++ RAII is a hack BTW, less a resource management facility than a primitive you can use to build one, always with the sad side effect of forcing programmers to wrap their cleanup code in classes even when it's an ill fit conceptually.) So yes, in practice in real-life teams, manual memory management does lead to more work and more bugs. Only somebody who has never seriously tried to use more than a small fashionable subset of languages could claim otherwise, or that they're not using memory management at all when in fact that's only true for toy programs.

I am ready to believe that you, personally, introduce numerous bugs in code you write, and then blame them on averyone else and on everything but your own bad habits.

But that experience does not generalize. Am I spectacularly lucky in my generally competent colleagues? I doubt it.

Well, apparently you are indeed.

https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

https://support.apple.com/en-us/HT212805

https://support.apple.com/en-us/HT212622

https://support.apple.com/en-us/HT212531

But maybe Apple, Google and Microsoft just aren't able to hire the right kind of highly skilled C++ devs that would write such perfect code, despite having a seat at ISO, and being clang/LLVM contributors.

Apple, Google, and Microsoft all employ very many competent programmers. But they share the problem that they need to hire many more programmers than are both competent and eager to work for them, and so must make do for the rest. It is a much easier task to select a place to work with competent colleagues. Thus, there is no inconsistency.

Perfection is not needed. Ordinary good code suffices. Good code using modern C++, or current Rust, is easier than in older languages (among which count older C++). When bad code is extra work, it becomes an unattractive alternative even to the lazy, leaving its production mainly to the masochistic and the aggressively incompetent, who are often the same.

So the ideal programmer matra that C folks keep stating that has unfortunely taited the C++ community, despite the facts of security exploits and no such people actually existing for the last 40 years.

Here is the thing, when the ISO C++ leaders, and major C++ contributors, push for a change, it is time to start doing some self reflection.

It would help discussion a great deal if you were to actually read what you are about to reply to, and reply to that, rather than just making up something entirely unrelated that you wish had been said instead, and then spouting foolish remarks about something no one has seen or said.

That personal shot was just childish. The moderators chose to ignore the flag, but it was deserved anyway and that's all it deserved.

Reply on news.ycombinator.com