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

Practical Garbage Collection - Part 1: Introduction

worldmodscode.wordpress.com

Post reply on HN
Print view View original

21–30 of 39 posts

Re: Practical Garbage Collection - Part 1: Introduction

#21

Post by nradov »

pixie_ wrote: post #5

The complexity of generational garbage collection vs. the speed of manual collection, makes me feel like the happy medium of speed and simplicity is reference counting, like that found in objective-c. iPhone apps are fast, but take a bit longer to design, develop, and debug due to memory management issues. Though with experience these can be minimized. It probably isn't possible without a ton of modification, but I w…

Reference counting as in Objective C may be a happy medium for now, but that won't last. As the underlying hardware and VMs in mobile devices continue to improve, the need for developers to spend extra time on memory management will be seen as more and more of an unnecessary burden.

Re: Practical Garbage Collection - Part 1: Introduction

#22

Post by ScottBurson »

pixie_ wrote: post #5

The complexity of generational garbage collection vs. the speed of manual collection, makes me feel like the happy medium of speed and simplicity is reference counting, like that found in objective-c. iPhone apps are fast, but take a bit longer to design, develop, and debug due to memory management issues. Though with experience these can be minimized. It probably isn't possible without a ton of modification, but I w…

There's no free lunch.

While GC requires tuning for the best performance, (pure) reference counting imposes a different cost: because it can't collect circular structures, the programmer has to break cycles herself. This clutters the application code. So you can't simply take a program written to run on a GC platform and move it to a reference counting platform unmodified.

Alternatively, you could use both: do most of your reclamation with reference counting, but throw in an occasional GC to collect circular structures. CPython, the most commonly used Python implementation, does this. I doubt it is the best thing for performance, but CPython isn't very fast anyway.

Re: Practical Garbage Collection - Part 1: Introduction

#23

Post by oconnor0 »

rubashov wrote: post #15

> The default choice of garbage collector in Hotspot is the throughput collector, which is ... entirely optimized for throughput I just want to confirm this is true? Say you're doing a long running simulation. You don't care about pauses at all. You just want it to finish fast. The default GC with no particular options is the way to go?

I'd say, odd are, that if you're just interested in throughput, the standard Hotspot GC without any options isn't going to give you optimal performance. I've found that, like gtani, mentions you'll have to spend time tuning to get the performance you want.

In a similar situation, I found that the Parallel Old was, by far, the fastest (throughput) collector.

Re: Practical Garbage Collection - Part 1: Introduction

#24

Post by gtani »

oconnor0 wrote: post #23
rubashov wrote: post #15

> The default choice of garbage collector in Hotspot is the throughput collector, which is ... entirely optimized for throughput I just want to confirm this is true? Say you're doing a long running simulation. You don't care about pauses at all. You just want it to finish fast. The default GC with no particular options is the way to go?

I'd say, odd are, that if you're just interested in throughput, the standard Hotspot GC without any options isn't going to give you optimal performance. I've found that, like gtani, mentions you'll have to spend time tuning to get the performance you want. In a similar situation, I found that the Parallel Old was, by far, the fastest (throughput) collector.

I'd say low fruit are -server, Xmx, Xms and MaxInlineSize and looking for boxing/unboxing. At the other extreme, is it worth it to your company to spend a few weeks reading the Hunt/John book and benchmarking thoroughly?

Re: Practical Garbage Collection - Part 1: Introduction

#25

Post by lmkg »

bitops wrote: post #9

A very good writeup, but one thing always confuses me. What is meant specifically by the "heap" and "stack"? I know what a stack is, but "heap" gets thrown around in many different contexts and I've yet to find any explanation that made it clear. If anyone has a good explanation or good links for those two terms in this context, I'd be very grateful. Thanks! [EDIT: thanks everyone for the answers so far!]

This looks pretty well-answered already, but I'll throw in my $0.02.

The stack and heap are the two main regions of memory where data can live in a program. They are (somewhat unhelpfully) named after the data structures originally used to represent them. Pretty much all modern languages have a concept of a stack and a heap, although there are differences both in how explicit they are, and in implementation details.

The stack is the function call stack, used to store data local to a function call. It behaves like a traditional stack, with push and pop operations. When you call a function, a new stack frame is pushed onto the stack, which contains all of the local variables that are only accessible inside that function call. When that function returns, it pops its stack frame (and sends its return value, somehow). The language scoping rules determine how one function may access the contents of an earlier stack frame that called it, but stack frames are basically deleted and inaccessible after they are popped (a source of errors in C).

The heap is the region of memory where you put data that lives longer than the function that created it. Heap behavior is far less specified, and more variable, between languages than stack behavior is (and involves the OS more), but if you're passing around pointers or references to an object you're probably using the heap. In languages that have them, the malloc and new operators usually mean "put this on the heap." In languages with a notion of reference types and value types, reference types are usually heap-allocated by default.

The distinction between the two types of storage is more important in some languages that others. It's really important in C, where you have to manually manage all your memory, but some of the more dynamic languages (especially everything-is-an-object ones) use the heap for all user data, and the call stack only for implementation details.

Languages also vary greatly in how much control you have over where things get put. On one extreme, C lets you put any type in any location, with malloc, while on the other I am not aware of any way in JavaScript to control object lifetime. Java and C# both distinguish between value-types (stack-allocated by default) and reference-types (heap-allocated by default), but C# allows user-defined value-types while Java does not. Common Lisp has a standardized way to tell the compiler that it is safe to stack-allocate a value (of any type). And so on.

Re: Practical Garbage Collection - Part 1: Introduction

#26

Post by oconnor0 »

gtani wrote: post #24
oconnor0 wrote: post #23

Earlier quoted context omitted.

I'd say, odd are, that if you're just interested in throughput, the standard Hotspot GC without any options isn't going to give you optimal performance. I've found that, like gtani, mentions you'll have to spend time tuning to get the performance you want. In a similar situation, I found that the Parallel Old was, by far, the fastest (throughput) collector.

I'd say low fruit are -server, Xmx, Xms and MaxInlineSize and looking for boxing/unboxing. At the other extreme, is it worth it to your company to spend a few weeks reading the Hunt/John book and benchmarking thoroughly?

Interesting. I've definitely looked for & removed boxing/unboxing. I haven't touched MaxInlineSize tho.

What performance improvements/degradations have you seen in altering MaxInlineSize?

Re: Practical Garbage Collection - Part 1: Introduction

#27

Post by aaronblohowiak »

rwmj wrote: post #7
pixie_ wrote: post #5

The complexity of generational garbage collection vs. the speed of manual collection, makes me feel like the happy medium of speed and simplicity is reference counting, like that found in objective-c. iPhone apps are fast, but take a bit longer to design, develop, and debug due to memory management issues. Though with experience these can be minimized. It probably isn't possible without a ton of modification, but I w…

Unlikely to happen. Reference counting has poor interaction with the CPU memory hierarchy: It makes all objects larger, making the working set correspondingly larger, meaning your data cache is less effective. It makes code larger because of the extra ref counting twiddling code. Larger code means a less effective instruction cache, as well as being slower because of all the extra operations performed. Reference coun…

Gc pauses suck the "magic" out of interactive programs. The great thing about obj-c is that it I trivial to have a c array of vanilla c structs, so your performance sensitive code is still slim and hot. (size and cache locality.)

My iOS audio programming mixes c for audio processing and obj-c for ui and control quite effectively.

Re: Practical Garbage Collection - Part 1: Introduction

#28

Post by aaronblohowiak »

nradov wrote: post #21
pixie_ wrote: post #5

The complexity of generational garbage collection vs. the speed of manual collection, makes me feel like the happy medium of speed and simplicity is reference counting, like that found in objective-c. iPhone apps are fast, but take a bit longer to design, develop, and debug due to memory management issues. Though with experience these can be minimized. It probably isn't possible without a ton of modification, but I w…

Reference counting as in Objective C may be a happy medium for now, but that won't last. As the underlying hardware and VMs in mobile devices continue to improve, the need for developers to spend extra time on memory management will be seen as more and more of an unnecessary burden.

With ARC, the only extra time is spent avoiding circular data structures, which is quite easy.

Re: Practical Garbage Collection - Part 1: Introduction

#29

Post by eternalban »

rubashov wrote: post #15

> The default choice of garbage collector in Hotspot is the throughput collector, which is ... entirely optimized for throughput I just want to confirm this is true? Say you're doing a long running simulation. You don't care about pauses at all. You just want it to finish fast. The default GC with no particular options is the way to go?

This is a quite excellent brain dump from a Twitter software engineer. Highly recommended: http://www.slideshare.net/aszegedi/everything-i-ever-learned...

Re: Practical Garbage Collection - Part 1: Introduction

#30

Post by nhebb »

lmkg wrote: post #25
bitops wrote: post #9

A very good writeup, but one thing always confuses me. What is meant specifically by the "heap" and "stack"? I know what a stack is, but "heap" gets thrown around in many different contexts and I've yet to find any explanation that made it clear. If anyone has a good explanation or good links for those two terms in this context, I'd be very grateful. Thanks! [EDIT: thanks everyone for the answers so far!]

This looks pretty well-answered already, but I'll throw in my $0.02. The stack and heap are the two main regions of memory where data can live in a program. They are (somewhat unhelpfully) named after the data structures originally used to represent them. Pretty much all modern languages have a concept of a stack and a heap, although there are differences both in how explicit they are, and in implementation details.…

There are several things I've never had a good understanding of regarding the stack. How big is the stack? Is it a fixed size dictated by the architecture of the processor? I know I've written recursions that overflow it. Other than gut feel and catching an exception after the fact, how do programmers know when their program might overflow it?
Post reply on HN