Garbage Collection vs. malloc/free

https://groups.google.com/forum/#!topic/mechanical-sympathy/1TMjVjyyMmA

by pron • 13 years ago

60 56 13 years ago

groups.google.com

jrochkind1• 13 years ago

What makes a difference is gc pauses. Imho if you can live without managed memory. You can do this in java as well and eliminate gc pauses.

Wait, how can you turn off GC'd managed memory in Java, and do it yourself? I didn't know you could do that in Java?

pron5• 13 years ago

You don't turn it off, but you can use off-heap memory (with direct ByteBuffers) and manage it yourself. Some Java applications manage some part of their memory off-heap, but this is a bad idea unless the allocated objects have a well-defined lifecycle.

russfrank• 13 years ago

http://stackoverflow.com/questions/9323416/using-memory-allo...

jamii• 13 years ago

You can even write c-like structs over byte-buffers - https://github.com/ztellman/vertigo

_pmf_2• 13 years ago

Same for plain Java instead of Clojure: http://javolution.org/target/site/apidocs/javolution/io/Stru...

fauigerzigerk• 13 years ago

Now everyone will tell you that you can use ByteBuffer or sun.misc.Unsafe to keep memory off-heap and hence out of sight of the GC.

BUT what that means is that you have create your own custom implementations of the data structures you need and you'll have to write your own memory allocator.

Unless that memory area holds just a simple data BLOB (like a video file) you're always going to be much more productive implementing the entire thing in C++.

pjmlp6• 13 years ago

Unless that memory area holds just a simple data BLOB (like a video file) you're always going to be much more productive implementing the entire thing in C++.

Or use a GC enabled systems programming language, that provides control over what is allocated via GC or via other means.

JoshTriplett• 13 years ago

Java's garbage collection is far from the state of the art in GC technology. While there are some non-standard JVMs that have advanced GC (such as IBM's real-time garbage collector), the standard JVM does not.

Current-generation garbage collectors have far better performance, and many research GCs support concurrent, pause-free collection.

(And that leaves aside the non-performance benefits of a GC, in terms of engineering simplicity and bug elimination.)

dman• 13 years ago

Any pointers on the state of the art?

pjmlp6• 13 years ago

http://www.azulsystems.com/technology/c4-garbage-collector

bnolsen• 13 years ago

In language garbage collection just makes implementing a compiler that much harder to do and frankly bloats up the runtime. Basic c++ shared pointers take up pretty much 90+% of what people need in GC (non stupid software architecture decisions should make up the remaining 10%).

I have seen problems with stalling caused by kernel memory heap defragging on linux resulting in some serious thrashing. What that means is that the issue of heap fragmentation can be a problem regardless of which language used.

pjmlp6• 13 years ago

Unless you happen to have a compacting GC. :)

gillianseed• 13 years ago

Well since compacting means the expensive task of moving managed memory blocks around to free larger sections that solution certainly comes with a big penalty of it's own.

Better to avoid heap fragmentation to such extents by applying a better allocation strategy imo.

gsg3• 13 years ago

Reference counting, even ignoring the additional expense C++ places on std::shared_ptr by requiring it be thread safe, is far too slow for allocation heavy languages. Only "we don't give a damn" implementations (like CPython) use it, because it is simply not competitive.

pcwalton2• 13 years ago

Not necessarily true. See "Down for the Count?" ISMM 2012: http://users.cecs.anu.edu.au/~steveb/downloads/pdf/rc-ismm-2...

a8da6b0c91d• 13 years ago

shared_ptr may be slow (I don't know) but you actually make very little "garbage" in C++, so it's not a problem. You're simply forced by the language to have clear ownership of resources most of the time.

dilap2• 13 years ago

Objective-C uses ref counting and does alright... Hardly a language that doesn't prioritize performance.

praseodym• 13 years ago

iOS uses Automatic Reference Counting (ARC, http://en.wikipedia.org/wiki/Automatic_Reference_Counting) by having the compiler add reference counting instructions, while refraining from having the developer add tedious reference counting instructions themselves. I'm not sure if there are significant performance advantages over proper GC.

It's worth noting that Apple has implemented GC in Objective-C on OS X before, but deprecated that in favour of its ARC implementation -- probably because its garbage collection implementation was no good at all (performance-wise).

nly• 13 years ago

std::shared_ptr is not thread safe, only the control block shared between all of the std::shared_ptr objects is thread safe. This means you only get a locking penalty when shared_ptr objects are constructed, copied, or destroyed, but not moved, dereferenced, or casted.

Both construction and destruction will allocate or can release memory, respectively, which I would think would bottleneck before any atomics or memory barriers inside shared_ptr. To me, the first likely port of call for improving performance in these cases is therefore a custom memory allocation strategy like a memory pool.

Copying can be a concern, but most containers and standard algorithms should be move aware now. You should be moving shared_ptr's far more often than you copy them.

All that aside, thread-safe by default seems to be the sane decision in this era.

ExpiredLink• 13 years ago

shared pointers? You must be joking!

betterunix3• 13 years ago

"In language garbage collection just makes implementing a compiler that much harder to do"

A simple copying or mark-and-sweep collector is far easier to write than even basic dataflow-analysis optimizations. Implementor effort is hardly an argument against garbage collection; implementing efficient garbage collection is no worse than implementing a good optimizer or efficient code generation.

"Basic c++ shared pointers take up pretty much 90+% of what people need in GC"

They do so in a way that is right in the programmers face, adding needless effort to writing software, and can actually wind up being slower than a modern garbage collector. Shared pointers are a mistake, not quite as bad as auto_ptr but pretty bad nonetheless; the committee should have just introduced a garbage-collected smart pointer class and kept things simple (I guess that would not be the C++ way, though).

pjmlp6• 13 years ago

Actually the discussion at the newsgroup is more about Java's GC vs malloc/free.

In GC enabled systems programming languages like the Oberon family, Modula-3, D, Sing#, one has finer control over the types of available memory.

- The usual GC allocated memory with the usual set of possible GC implementations

- Stack objects

- Global objects statically allocated

- Manual memory management inside unsafe blocks via untraced GC references

Not all GCs are made alike.

pron5• 13 years ago

Real-time Java (RTSJ) actually has some very cool mechanisms for fine-tuned control over allocations.

banachtarski2• 13 years ago

The benefit of malloc/free (or new/delete) is that you have control over your own memory layout to handle optimizations like cache alignment, keeping relevant data contiguous, deferring pauses that would introduce latency and such.

pron5• 13 years ago

Memory layout is a separate discussion. The kind of layout optimizations you're describing require work, and if you're willing to put in this work, you can do it in GCed environments as well (like the JVM, with finer-grained control coming in future versions).

Otherwise, several/most of the JVM's GCs do a very good job of handling this for you. Objects that were allocated consecutively by the same thread will tend to be kept close together in memory.

banachtarski2• 13 years ago

That's contiguity but alignment is a different thing. At a certain point though, the two things become one and the same. On the one hand, you could put in layout optimizations in a GC system. On the other hand, you can use things like shared_ptr and effectively write your own GC even.

I guess the debate really isn't an A vs B thing. It's just a spectrum and deciding which side of the spectrum you want to start on.

_pmf_2• 13 years ago

In my experience the biggest difference is stack allocation

This is the only voice of reason in this thread full of bullshit by monkeys who have obviously never used C to any extent.

ryanobjc• 13 years ago

I'm not sure I'd call Gil Tene a "monkey who has obviously never used C".

But hey.

pjmlp6• 13 years ago

Yes we did.

Some of us are even older than C, and are thus aware that there used to be a time and age where C only mattered for UNIX developers.

Pxtl2• 13 years ago

I loathe the fact that all intermediate options get left off the table - reference-counting, or single-ownership-with-weak-references, or anything else short of memory-gobbling full GC that breaks your real-time guarantees.

And C++'s hideous shared_ptr system isn't a good thing to point to.

lmm2• 13 years ago

If you have real-time requirements reference counting is worse than GC; it has the same problem of some operations sometimes taking an unexpectedly long amount of time, and the worst-case guarantees are weaker.

Single ownership with weak references is effectively what you have in C, though I guess compiler support for distinguishing which references are weak or strong is nice.

Pxtl2• 13 years ago

Weak reference implies a safe error result if you access a weak reference after a "strong" reference has been released, not undefined behavior. Not just a pointer.

For refcounting and real-time, just let me leak the cycles. The non-realtime part of reference counting is the cycle detection, let me control the cycle sweeps and everybody's happy.

millstone2• 13 years ago

I think you are referring to deallocating an object graph. Under GC, the cost of deallocating an object graph depends on global state, such as how many unrelated objects are allocated. But in an RC scheme, the cost of deallocating an object graph depends only on that graph itself. This makes RC easier to reason about. The "unexpectedly long" cases can be isolated and optimized separately.

Consider a soft real-time environment like a game. Under RC, the time required to render a single frame depends only on the work done in that frame. Get it to 16 ms and you're done. But under GC, deallocation work can accumulate. A frame that would otherwise render in 16 ms may take much longer, due to the laziness of previous frames. That makes it harder to optimize, and indeed you'll often see advice like "frames must do zero GC allocations." Yikes!

Things may be different in hard real-time systems, which I know use specialized allocation schemes optimized for worst-case latency instead of bandwidth.

hershel• 13 years ago

I believe "Hard Real-Time Reference Counting without External Fragmentation" By T Ritzau[1] solves the problem of unbounded reference counting times.

[1]Google has pdf. BTW, how do i extract a long living pdf link from a google link ?

rayiner2• 13 years ago

The stock malloc() in Linux, OS X, Windows, etc, can't make any sort of real time guarantee either.

bowyakka• 13 years ago

Its interesting people forget that refcounting is quite cache destroying in the CPU, each upref invalidates memory locations in cache lines that are scattered throughout the address space.

rayiner2• 13 years ago

People tend to conflate garbage collection with Java's object model, but the two things are distinct. Most of the time when you're talking about performance limitations in Java, you're really concerned about Java's object model, not the GC.

Garbage collection limits your object model, but Java's is much more limited than required for garbage collection. For example, in C++, you might pass small structs on the stack or in registers, while in Java you pass a pointer to a heap allocated object. But there is no reason a garbage collector can't handle value objects allocated on the stack, and indeed the CLR supports that feature.

All a garbage collector prevents you from doing is hiding pointers in integers and the like. But that's not as significant a limitation as not being able to say flat arrays of structs, something that is totally compatible with garbage collection.

pron5• 13 years ago

Java value-types (+ arrays) are in the works. The JVM already does what is known as "scalar replacement" (http://www.stefankrause.net/wp/?p=64) automatically allocating some non-escaping objects on the stack.

haberman• 13 years ago

It's amusing to me that on the same thread GC proponents say that high-performance GC is easy (https://news.ycombinator.com/item?id=6485114) and that Java's GC is "far from state of the art" (https://news.ycombinator.com/item?id=6483704).

And so the perpetual argument goes: GC is superior to manual memory management (the latter of which is "adding needless effort to writing software"), and the performance is just as good, and the cases where performance is not just as good will be fixed Real Soon Now.

betterunix3• 13 years ago

I'd like to point out that I did not say that a high-performance GC is easy. What I actually said is that a simple GC is easier than simple automatic optimizations. A high-performance GC is the same level of difficulty as good automatic optimization.

Garbage Collection vs. malloc/free

Related Stories