
Off-heap Memory in Apache Flink and the curious JIT compiler - jtagx
http://flink.apache.org/news/2015/09/16/off-heap-memory.html
======
jjoonathan
I've never been able to figure out the use case that garbage collectors cater
to.

For short "one-off" programs, "let process exit clean it up" is not only a
reasonable strategy but one that GCs themselves often implement under the
hood. For long-lived programs, nothing short of divine intervention is going
to relieve the programmer from organizing object relationships to control
lifetimes (the "hard work" of manual memory management). GCs get rid of stupid
leaks that take 10 seconds to detect and fix but they don't stop your undo
queue from holding onto everything since the dawn of time or any of the other
classic memory management gotchas that take serious effort to understand and
solve. They then add a bunch of nontrivial gotchas of their own: thrashing,
stalls, encapsulation penalties, and a cloud of obnoxious complexity should
you discover a need to do something yourself (as we see here).

This is the third time today I've (over)heard someone fighting a garbage
collector over something that ought to be trivial and would be in a "manual"
system. I continue to wonder if GCs are worth the trouble.

~~~
whateveracct
GC allows advanced immutable data structures to "just work." So that's one
use-case. They are always very complicated linked structures that would be a
pain to manage manually. Immutable programming is all about making many, many,
many short-lived objects, and modern GCs are great at handling those.

------
gopalv
What's interesting about this post is that the regular heap access is fast.

But the sub-class implementation is hit rather badly, which is rather more
about the state of the JIT than anything else.

HeapMemorySegment (standalone) : 1,441 msecs

OffHeapMemorySegment (standalone) : 1,628 msecs

HeapMemorySegment (subclass) : 3,841 msecs

OffHeapMemorySegment (subclass) : 3,847 msecs

