Hacker News Reader

Comment by rturben | Hacker News Reader

I know that in things like games and other highly concurrent applications that object pooling is a must, otherwise you inevitably run in to the problem of attempting to update or render some game object that's died and been deleted. Maybe it's less common in other types of application development?

View on HN

> update or render some game object that's died and been deleted

Woah, woah. No, object pooling is not for that case and definitely doesn't help with that. If you've re-used the object for something else and you've still got a reference to it - and you're updating it - you've got some seriously nasty bugs and randomly broken code.

Object pooling is not a 'must'. You need object pooling when you have a real time app and your total create/delete bandwidth exceeds the garbage collectors ability to process it in the 'early generation', forcing eventual 'stop the world' GC.

In fact, object pooling makes this problem worse. You suddenly have to remember to remove objects from the pool at the right time, resulting in memory leaks if you forget or use-after-free (though not the exploitable kind) if you do it too early. It's better than unsafe manual memory management from a security perspective, but it's not any better from an ergonomic perspective.

Yes, ergonomics suck. It's particularly frustrating since a lot of things that end up pooled are confined to current thread execution (e.g. request) and could easily be stack alloc'd if that facility was there. Along the same lines, sharing messages across threads where one would simply like to memcpy into a ringbuffer become a pain in the rear.

In Java8, escape analysis usually catches most of the objects that can be moved to the stack, and they don't touch the heap anyway.

https://en.wikipedia.org/wiki/Escape_analysis http://www.burnison.ca/articles/escape-analysis-stack-alloca...

It would be nice to be able to control it though. (value objects?)

Escape analysis hasn't lived up to its promises/potential, IMO. Current Hotspot uses control flow insensitive escape detection, meaning an object that escapes on any path, even if that path is never taken, is considered escaping. This can be improved to be CF sensitive, and Graal does that.

Secondly, beyond trivial examples, sufficient inlining needs to occur for compiler to have full horizon, and that can fail for a variety of reasons, even with run to run variance of exact same code shape.

As you say, there's no control and you're fully at the mercy of the compiler's mood that day. This is well into Sufficiently Smart Compiler land ...

The bottom line is that anyone for whom those allocations can be problematic take manual measures to ensure they don't happen and do not rely on EA.

Value types should help for a few reasons, however they appear to be somewhat limited (e.g. immutable, cannot be passed by ref).

Reply on news.ycombinator.com