Comment by CyberDildonics
3 hours ago
Modern C++ allocators don't use a heap structure either.
"Yes, malloc uses a heap data structure to allocate memory dynamically for programs. The heap allows for persistent memory allocation that can be managed manually by the programmer."
"How Malloc Works with the Heap
Heap Data Structure: Malloc uses a heap data structure to manage memory. The heap is a region of a process's memory that is used for dynamic memory allocation.
Memory Management: When you call malloc, it searches the heap for a suitable block of memory that can accommodate the requested size. If found, it allocates that memory and returns a pointer to it."
How the JVM does allocations for all it's collectors is in fact a bump allocator in the heap space.
This doesn't make sense. It's one or the other. A heap isn't about getting more memory or mapping it into a process space, it is about managing the memory already in the process space and being able to free memory in a different order than you allocated it, then give that memory back out without system calls.
https://www.geeksforgeeks.org/c/dynamic-memory-allocation-in...
https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
JVM allocations are typically pointer bumps, adding a number to a register.
I think you are mixing up mapping memory into a process (which is a system call not a register addition) and managing the memory once it is in process space.
The allocator frees memory and reuses it within a process. If freeing it was as simple as subtracting from a register then there would be no difference in speed between the stack and the heap and there would be no GC pauses and no GC complexity. None of these things are true obviously since java has been dealing with these problems for 30 years.
This is why the JVM is so fast at allocation, much faster than C++ can be
Java is slower than C++ and less predictable because you can't avoid the GC which is the whole point here.
The original point was that you have to either avoid the GC or fight the GC and a lot of what you have talked about is either not true or explains why someone has to avoid and fight the GC in the first place.
You're wrong for like 6 different reasons.
Java does do bump pointer allocation. The key is that when GC runs, surviving objects get moved. The slow part of GC isn't the allocation (GCs generally have much faster allocators than malloc). The slow part is the barriers that the GC requires and the pauses.