11 ms·

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 attem

by rturben 11y ago

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?

RyanZAG 11y ago
> 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.
- pcwalton 11y ago
  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.
  - vitalyd 11y ago
    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.
    - RyanZAG 11y ago
      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 https://en.wikipedia.org/wiki/Escape_analysis http://www.burnison.ca/articles/escape-analysis-stack-allocated-objects http://www.burnison.ca/articles/escape-analysis-stack-alloca... It would be nice to be able to control it though. (value objects?)
      - vitalyd 11y ago
        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).

by rturben 11y ago

RyanZAG 11y ago

> 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.

pcwalton 11y ago
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.
- vitalyd 11y ago
  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.
  - RyanZAG 11y ago
    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 https://en.wikipedia.org/wiki/Escape_analysis http://www.burnison.ca/articles/escape-analysis-stack-allocated-objects http://www.burnison.ca/articles/escape-analysis-stack-alloca... It would be nice to be able to control it though. (value objects?)
    - vitalyd 11y ago
      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).