4 ms·
> GC-free allocations for tight loops Java deals pretty well with that case already. Small ephemeral objects have the allocation costs closer to C-style stack
by marginalia_nu 3y ago
> GC-free allocations for tight loops
Java deals pretty well with that case already. Small ephemeral objects have the allocation costs closer to C-style stack-allocation than heap allocation in most cases (due to TLAB etc.)
This has far bigger implications for databases, kv-stores, and similar, which are currently severely hamstrung by only being able to memory map 2 Gb at a time.
> I bet that games could very well be rewritten to use this to allocate memory. Though the layout and varhandles looks tedious to use, but may be it'd be fine.
I mean you could conceivably use it for an ECS system or something like that, scratch allocation, but many of those patterns from the C++ world solve problems that Java largely doesn't have (i.e. heap fragmentation)
- nvm0n2 3y agoECS is designed to solve cache locality, not heap fragmentation.
- pjmlp 3y agoThat is data oriented design, not ECS.
- nvm0n2 3y agoECS is data oriented design, no? That's kinda the whole idea of it.
- pjmlp 3y agoNo, it is a way to organize code in interfaces/components instead of classes and inheritance. It doesn't have anything to do with transforming arrays of structs into struct of arrays for better cache access.
- xeonmc 3y agoCould you possibly be conflating Entity-Component systems with Entity-Component-System systems?
- nvm0n2 3y agoI'm pretty sure in the context of game engines that's exactly what it means. https://en.wikipedia.org/wiki/Entity_component_system https://en.wikipedia.org/wiki/Entity_component_system Common ECS approaches are highly compatible with, and are often combined with, data-oriented design techniques. Data for all instances of a component are commonly stored together in physical memory, enabling efficient memory access for systems which operate over many entities.
- riku_iki 3y ago> Small ephemeral objects have the allocation costs closer to C-style stack-allocation than heap allocation in most cases (due to TLAB etc.) so, I have some code with one loop, which reads strings from file and does some computations, when I add single "new SomeSmallObj()" there which I would allocate on stack in C, it starts working 2 times slower. How can I debug/reason/improve this case?..
- vips7L 3y agoYou haven't provided enough details of your object allocation. It depends entirely on escape analysis and whether the JIT thinks the object escapes. If you're doing a simple non escaping allocation it shouldn't matter: var i = new SmallObject().getI(); Here's a good reading on it: https://gist.github.com/JohnTortugo/c2607821202634a6509ec3c321ebf370 https://gist.github.com/JohnTortugo/c2607821202634a6509ec3c3...