And suddenly...

...everyone in /anus/ seem to hate GC?

Here is just one old C++ bitfucker (probably Straustrup himself). He sees that his language's life is coming to end and feels bad for his now useless skills of writing template RAII monstrosities.

GC requires 4x memory in order not to grind a program to a standstill. GC happens whenever the hell it likes, and pauses everything. GC is a pain to work with whenever a complex data structure is needed, because it doesn't know when any particular node is not needed anymore.
So yeah, I hate forced GC.

>>3

1. You can still have unmanaged objects.
2. Heap size can be limited to the one, which can be handled in real-time.
3. By avoid circular-references, you make way for algorithms, like the one in http://bbs.progrider.org/prog/read/1401156449 which have guaranteed execution time.

>>4
1. In what language? And how do I use libs which use GC? With pain, that's how.

2. But the overhead of GC will not go anywhere, which means less things can be held in memory at the same time. Read the paragraph on garbage collection here:
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
and don't miss the graph:
http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png

3. By not avoiding circular references, I make way for lots of more algorithms and data structures. Even my Cormen "Intro to Algorithms" has lots of stuff that would be a pain in a GC environ.

>>5

In what language? And how do I use libs which use GC? With pain, that's how.

Most GCs have weak weak references. I know SBCL, CLR and JVM provide them.

But the overhead of GC will not go anywhere, which means less things can be held in memory at the same time. Read the paragraph on garbage collection here:

malloc produces a lot more overhead.

By not avoiding circular references, I make way for lots of more algorithms and data structures.

If you really need circular references, you can simulate pointers using integers: create an array of objects, and instead of referencing them, keep indices to this array. No setting some index to NIL would efficiently GC the object.

>>6
Malloc. Produces more overhead than GC. What the fuck am I reading.

>>7
It's true in the case of a GC where losing/creating an object doesn't directly correspond to freeing/acquiring memory. The system could allocate big blocks only and handle minor allocations by playing around with these blocks internally, thus bypassing the syscall malloc would require.

>>8
That's doable with manual memory management too.

>>9
That's not the point. Please put more effort into your ``trolling''.

>>7
Computing overhead? It can in pathological cases with a naive malloc. allocating n objects is naively O(sum(1..n)) since it has to walk the entire freelist on each allocation (again, naive implementation, pathological case), wheras a copying collector can simply update a pointer, then do a collection (in something like O(n)) once in a while.

GC is a tradeoff between total throughput (infrequent collections) and responsiveness / low memory overhead (fequent collections.) Java looks fast in benchmarks but most JVMs eat memory and are unresponsive, guess which strategy they use.

A naive malloc will cause some pretty nasty fragmentation too, so it might peak worse than a copying collector, depending on exactly what is allocated.

>>9
Modern malloc implementations do this to a degree. They basically try to minimize the amount of freelist walking and the amount of fragmentation and arenas are the answer. This is close to the midpoint between GC and naive malloc, btw.

>>10
Then what is your point, troll?

>>8

the syscall malloc would require

Not sure if retarded, or just a troll...

All the computation-heavy code (full-scale games, scientific computations) is written in languages without forced GC even today.

Anyone who thinks that GC can be efficient should try running Eclipse.

>>14
Eclipse would be a lot faster if it wasn't Java though. It's not just that Java has a poor collection strategy, but Java allocates objects at the drop of a hat, making n very large.

GC is fine and it has its place just like everything else. If you evangelize non-GC you're just as bad as the OOP crowd.

>>15
Java has one of the best forced-GC runtimes in the industry. If even Java's memory consumption is bad, then where is the non-shit GC?

>>16
Of course it has its place. It has its place where Python and Javashit have their place - for writing apps and web guestbooks. But for real, bad-ass systems programming? Nope, not a single chance in hell.

If you think GC is slow why aren't you using compile-time GC just like Mercury?

But for real, bad-ass systems programming?

a sane person would not use anything other than C or assembly in systems programming

>>17
It has one of the best in the industry [i]according to benchmarks[/i]. See the rant above about infrequent collections. It has low overhead when all is said and done, as long as you don't start paging. There's also the fact that it allocates nearly everything.

The truth about good GC is it really depends on your application and environment. If you have infinite memory, let the OS collect for you on exit. If you can dedicate decandant amounts of memory to a single app, Java will be fast as long as you can tolerate the pauses.

Perl uses refcounts which is not GC to GC people but it's GC to everyone else. Pauses are rarely noticeable, and clean code rarely causes problems for the cycle collector.

The naive copying collector described in the SICP lectures is not at all bad for worst-case. It's very nearly linear time, and reduces fragmentation to zero. Run this often and you will have much less wasted memory than Java.

I don't know anything notable about the JavaScript GCs but Epic Citadel runs a lot better than Minecraft on my system, so I think the EichMonkey GC is probably pretty good when the allocation/deallocation patterns are clean. It makes sense, because Mozilla was obsessed with memory footprint, and collecting as early as possible is the best thing you can do for that with regards to the GC. They also went shopping around for allocators that combat fragmentation, which is a good combo.

You might have heard of Hans Boehm:

Copying collectors can also offer better worst-case space bounds than nonmoving collectors, particularly if real-time constraints are present. Thus they may be appropriate for certain embedded real-time applications.

However, he also says:

There is growing evidence that copying collectors are a poor choice for old objects in a typical desktop application. They often result in unnecessarily large memory footprints, and paging where none is really necessary. The net effect can be disastrous performance.

http://www.hboehm.info/gc/complexity.html (1995)

In the end, GC is not for everything, but it's fine for most games if you have a little headroom for a well-placed GC. Enforced GC is not so great for most AAA 3D titles, but that doesn't stop people from making Android ports of FPS games. If you can choose your GC (and what is subject to collection), things look very nice indeed. You can just put roots of data known to be transient in an arena (reasonably easy to do in C++ and friends) and collect on the arena. The cost is roughly: up to 2x memory overhead (for arena only), 2x the cost of pointer derefs (for arena only) and a collection in linear time on the number of objects allocated to the arena, run perhaps every frame.

So yeah, for heavy-lifting non-optional non-pluggable GC basically ruins your day. The more choices you have in GC the better, but you are replacing the effort of manual memory management with the need for somewhat specialist knowledge needed in choosing the strategy.

I like GC in scripting languages and in functional and math-oriented languages. Whatever naive GC is there usually suffices (some are awful though), and if it doesn't the languag is still suitable for prototyping most things.

>>20
why didn't the [ i ] and [ / i ] work?

>>21
It worked in the preview. It happened to me once before too with [m] and [/m].

>>19
Because I didn't know about it? Region-based memory management looks much nicer than forced GC, I'll dig into it, thanks.

>>23
You will hate me for this, but Rust uses regions.

>>19

a sane person would not use anything other than C or assembly in systems programming

And that's why the NSA is rooting everyone's anii.

>>24
I hate you

>>24
Rust shill detected.

>>27

What's a "shill"? I remember "shill jobs" in the
Thieves Guild in Skyrim, they were about planting
false evidence in people's houses. So are /prog/
shillers the ones who post illegal stuff to make
the government shut it down?

>>28
i'll plant something in your anus if you catch my drift

>>28
Also heist jobs, sweep jobs, numbers jobs, bedlam jobs, fishing jobs. Good times. Except you had to play it all in your head because vanilla Skyrim is a casual console piece of shit.