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

GC Tuning Confessions of a Performance Engineer

slideshare.net

Post reply on HN
Print view View original

41–50 of 98 posts

Re: GC Tuning Confessions of a Performance Engineer

#41

Post by astral303 »

jimrandomh wrote: post #34

Performance is nice, but correctness is more important. Complex programs written without any GC tend to have use-after-free and double-free vulnerabilities. Programs written using automatic reference counting only (without a way to catch cycles) tend to have memory leaks. If GC is killing performance, then that is a failure of the specific GC or programming language design. Don't blame the applications programmers fo…

Specifically about ArrayList -- there are specifically a bunch of projects (Goldman Sachs Collections, trove, FastUtil, Koloboke) that solve the array of primitives problem.

I would say that's a Java-standard-libary-specific problem.

Re: GC Tuning Confessions of a Performance Engineer

#42

Post by pron »

vitalyd wrote: post #19
pron wrote: post #13

Earlier quoted context omitted.

> You will never beat a tuned system without GC with a GC system because of all the instructions necessary to traverse references and such. That's not at all how it works. The generational hypothesis means that most objects die young. Allocating them is a simple, uncontended pointer bump in the thread-local allocation buffer (as fast as stack allocation), and freeing them is free, as they are never traversed. They ar…

I really dislike the comparisons of TLAB to stack allocation. Stack, by its nature, is going to be hot in cache. TLAB, once filled up, will be retired and possibly assigned to a different thread. But even if it's not assigned, it's constantly moving forwards, and not revisiting the same space. You'd need prefetch to be perfect, and then on top of that, you'd need to make sure that by the time you go to allocate again…

While everything you say is 100% true, it is also a second-order effect, with a much lower magnitude than the primary GC performance behavior for short-lived objects.

Obviously stack allocation is preferable to TLAB allocation (and there's no reason to allocate objects with stack scope on the heap), if only for the fact that it never triggers a collection. Nevertheless, Java allocation/collection of short-lived object is much closer in cost to stack allocation than to malloc/free.

Re: GC Tuning Confessions of a Performance Engineer

#43

Post by banachtarski »

duaneb wrote: post #37
pjmlp wrote: post #35

Earlier quoted context omitted.

Manual memory management only works in small teams with highly skilled developers, and even then there is a reason why so many CVE exploits are related to memory corruption. Even those highly skilled developers aren't failure prof.

Manual memory management (i.e. not GC) is a little disingenuous because it implies that it's entirely manual. In fact, there are many patterns (e.g. RAII) which make "brain dead" manual memory management possible. I'm not necessarily arguing this is a great way to go for a new team, but there are manual memory management strategies that can definitely scale. Among other things, it's not the only type of resource that…

Agreed. Sometimes, you don't even need RAII. You just let the stack unwind :)

But yes, RAII can make it pretty braindead (which is good)

Re: GC Tuning Confessions of a Performance Engineer

#44

Post by banachtarski »

pjmlp wrote: post #35
banachtarski wrote: post #5

Having worked with all sorts of GCs in the past, I basically stopped using them altogether some years ago in favor of manual memory management. I have to say, it's been liberating and so much easier to write performant code since I know what memory I need instead of relying on the computer to guess (and giving the computer hints as to how to guess). I have no doubt that GC research and systems is making good forward…

Manual memory management only works in small teams with highly skilled developers, and even then there is a reason why so many CVE exploits are related to memory corruption. Even those highly skilled developers aren't failure prof.

Man, the new generation of programmers are going to be in bad shape if the thought of stack unwinding or managing the heap yourself is left to the "highly skilled." Even if I was interviewing someone who only worked in a memory-managed language, I would hope that they'd at least be capable of understanding how to code without it.

These should be the fundamentals.

Re: GC Tuning Confessions of a Performance Engineer

#45

Post by Drdrdrq »

pjmlp wrote: post #32
bd_at_rivenhill wrote: post #30

Earlier quoted context omitted.

I think we will start to see less use of GCs in mobile going forward, especially now that Apple has deprecated GC in favor of automatic reference counting. The issues caused by the interaction between the memory hierarchy and the fragmentation that is naturally introduced by GC are difficult to measure, but nevertheless an important component of performance.

Lets not forget they did that, because they failed to produce a stable working GC for Objective-C.

Lets not forget Java failed to produce that too, they just dont seem to care. :)

Re: GC Tuning Confessions of a Performance Engineer

#46

Post by pjmlp »

banachtarski wrote: post #44
pjmlp wrote: post #35

Earlier quoted context omitted.

Manual memory management only works in small teams with highly skilled developers, and even then there is a reason why so many CVE exploits are related to memory corruption. Even those highly skilled developers aren't failure prof.

Man, the new generation of programmers are going to be in bad shape if the thought of stack unwinding or managing the heap yourself is left to the "highly skilled." Even if I was interviewing someone who only worked in a memory-managed language, I would hope that they'd at least be capable of understanding how to code without it. These should be the fundamentals.

Well I started coding in 1986, and have seen quite a few screw ups.

So yeah, small teams it works great.

Now scale that to developer teams > 30 on average, with high turnaround and multiple outside partners coming and going on project basis.

I have seen what off-shoring does to C and C++ code bases...

Re: GC Tuning Confessions of a Performance Engineer

#47

Post by pjmlp »

Drdrdrq wrote: post #45
pjmlp wrote: post #32

Earlier quoted context omitted.

Lets not forget they did that, because they failed to produce a stable working GC for Objective-C.

Lets not forget Java failed to produce that too, they just dont seem to care. :)

I didn't notice that JVM's GC do segfault all the time, with erratic behaviour depending on the libraries being linked.

Re: GC Tuning Confessions of a Performance Engineer

#48

Post by Jweb_Guru »

mkpankov wrote: post #38
vitalyd wrote: post #19

Earlier quoted context omitted.

I really dislike the comparisons of TLAB to stack allocation. Stack, by its nature, is going to be hot in cache. TLAB, once filled up, will be retired and possibly assigned to a different thread. But even if it's not assigned, it's constantly moving forwards, and not revisiting the same space. You'd need prefetch to be perfect, and then on top of that, you'd need to make sure that by the time you go to allocate again…

A stupid question: what's TLAB?

Thread local allocation buffer.

Re: GC Tuning Confessions of a Performance Engineer

#49

Post by duaneb »

pron wrote: post #14
duaneb wrote: post #8

Earlier quoted context omitted.

As with everything in engineering, this is a tradeoff. Not all access patterns work well with mark-and-sweep (or equivalent full traversal patterns). In particular, without needing to release or allocate memory, a GC pass wastes cycles. Furthermore, data structures must be compatible with the GC: traversal is proportional to the number of pointers (rooted or dangling) in the heap and stack at the time of running. Gen…

> traversal is proportional to the number of pointers (rooted or dangling) in the heap and stack at the time of running. That's not quite how it works. Traversal is proportional to the number of pointers changed since the last collection (HotSpot's GCs do card marking). I do agree there are tradeoffs, but they're much more nuanced than that. There is certainly a footprint tradeoff, and there is a latency tradeoff (th…

> Traversal is proportional to the number of pointers changed since the last collection (HotSpot's GCs do card marking).

True. I was just trying to make the point that GC comes with complexity cost, and this should be considered—it's not "free" for an arbitrary algorithm.

Re: GC Tuning Confessions of a Performance Engineer

#50

Post by vitalyd »

dumael wrote: post #40
evanpw wrote: post #33

Earlier quoted context omitted.

True, but you could do the same thing in any region of memory. The only thing that using "the stack" buys you is that there are a few special instructions to allocate / deallocate one machine word at a time (if you store the "top-of-heap" pointer in a specific register), and you get a bit more locality by virtue of return addresses being stored next to your locals and temporaries. (For x86 processors at least; maybe…

I'm almost positive that x86 doesn't really have special stack instructions, aside from call (push pc +sizeof(call)) onto $esp and jump. I know MIPS (and possibly other RISC architectures) don't have an implicit 'stack' register, just one that used by convention. They do have jump and link instructions which write $pc+4 into another register. Afaik, LLVM and quite possibly GCC just add/subtract $esp for the initial a…

There's also push/pop.
Post reply on HN