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.
In other words, preventing memory leaks is undecidable, but you can at least be sure you're not freeing useful memory.
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
