4 ms·
> This is an argument I don't understand. It is exceedingly common for performance sensitive applications in GC environments not to allocate either, because qui
by okasaki 11y ago
> This is an argument I don't understand. It is exceedingly common for performance sensitive applications in GC environments not to allocate either, because quite simply allocating/deallocating in any environment is expensive.
Is that possible? I thought all objects are heap allocated in Java?
- eropple 11y agoThey are. So don't reallocate them. Just use mutable objects that can be reset and object pools. (This has its own obvious drawbacks.)
- chrisseaton 11y agoNo this is bad advice in general! It causes the objects to permanently escape, with the knock-on that any objects stored in that object will also escape etc etc, and to move to the old generation. If you need objects, allocate and use them where you need them. This is more likely to allow scalar replacement, or at least more efficient collection while still in the young generation.
- Skinney 11y agoTrue, but object pools enables you to reuse objects, which in turn allows you to avoid or postpone GC (if done correctly).
- chrisseaton 11y agoBut object pools prevent escape analysis and scalar replacement of objects, which wouldn't create garbage in the first place.
- eropple 11y agoIn theory, this sounds true. In practice, it isn't. I've done pooled versus non-pooled tests of objects like Vector3's in libgdx and the difference in memory pressure is fairly huge. The JVM is really, really smart, but this is a well-understood area where you sometimes have to break the rules and do something stupid (and it is stupid) for the sake of perf.
- eropple 11y agoOh--and also consider that some of us (hi) aren't writing for HotSpot, yeah?
- kasey_junk 11y agoParticularly in concurrent contexts escape analysis offers you no help.
- Gankro 11y agoPrimitives aren't allocated. This is why we have `int` and `Integer`; Integer is a boxed int. Java has a fair amount of sugar around doing the change automagically. Also escape analysis is a thing Java can do to avoid heap allocating objects in general: https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#escapeAnalysis https://docs.oracle.com/javase/7/docs/technotes/guides/vm/pe...
- david-given 11y agoFun fact! Original Java, before they started adding autoboxing, had precisely one place which did heap allocation: the 'new' keyword (which is why it was a keyword). If you avoided the keyword, you could be sure you weren't using the heap. ...which meant you could run (a limited subset of) Java programs on very, very small devices. 8-bit microcontrollers. Such as Maxim's iButton devices, or smart cards. My memory says that the standard is called kJava, but it seems to be ungoogleable these days, so I could be wrong (and Oracle ate all of Sun's documentation).