4 ms·

This really is an apples to oranges comparison. In C++, you have to know the difference between stack allocations and heap allocations. If you aren't dynamica

This really is an apples to oranges comparison. In C++, you have to know the difference between stack allocations and heap allocations. If you aren't dynamically allocating anything; malloc and free performance has no bearing. As far as I know, Java has no reliable way to create an object purely on the stack (and it probably shouldn't. And even if you are dynamically allocating a new object in C++, if it has non-pointer children, it allocates that memory too in the same allocation call. It is true that a lot of allocations will slow down C++ a ton; but a lot of allocations can be avoided in C++ whereas in Java you don't get that fine of control. Even then; there is nothing about the malloc+free contract that prohibits you from having an implementation that does some of the things the author talks about. You can make a version of free that marks memory locations to be freed at the nth call of free. I'm curious on the source for this statement: > Java's collector can free an unlimited number of objects in time independent of the number of objects freed. That seems like it can't possibly be true in the generic case.

haimez 11y ago
It's true, because the time to free objects is not related to the number of objects freed- it IS dependent on the number of objects that AREN'T freed. The GC time (in a very general sense) is the amount of time it takes to traverse the live object graph.
- albinofrenchy 11y ago
  Isn't that true only for objects in the 'new' pool? Or does it actually compact the old pool every gc?
  - haimez 11y ago
    I'm not sure I see the connection you're trying to make. The specifics of old pool vs new pool (generation is the preferred term) are dependent on the GC config, but in no case can you find memory that can be freed by traversing a "dead objects" graph. Liveness is what drives the relationship between size and computation time. Big O notation stuff.
    - albinofrenchy 11y ago
      So my understanding of the new generation is that it's essentially a giant chunk of continuous memory and as you create new objects, you are just adding to the end of it. For whatever reason a GC event happens, and now you can traverse the live graph, and anything alive in the new generation gets copied to the old generation partition of memory. And now you just reset the counter for the new object pool, and voila, you've deleted a whole bunch of young objects just by not copying them. But once it's in the old generation, you run right into the same issue with fragmentation and having to keep track of where deleted objects are so you can reuse that space. If the idea is that you just keep doing memcopies for all the live objects to reuse the space and avoid looking at dead objects, I'd think that that is it's own performance issue?
- cha5m 11y ago
  Why is this the case?

haimez 11y ago

It's true, because the time to free objects is not related to the number of objects freed- it IS dependent on the number of objects that AREN'T freed. The GC time (in a very general sense) is the amount of time it takes to traverse the live object graph.

albinofrenchy 11y ago
Isn't that true only for objects in the 'new' pool? Or does it actually compact the old pool every gc?
- haimez 11y ago
  I'm not sure I see the connection you're trying to make. The specifics of old pool vs new pool (generation is the preferred term) are dependent on the GC config, but in no case can you find memory that can be freed by traversing a "dead objects" graph. Liveness is what drives the relationship between size and computation time. Big O notation stuff.
  - albinofrenchy 11y ago
    So my understanding of the new generation is that it's essentially a giant chunk of continuous memory and as you create new objects, you are just adding to the end of it. For whatever reason a GC event happens, and now you can traverse the live graph, and anything alive in the new generation gets copied to the old generation partition of memory. And now you just reset the counter for the new object pool, and voila, you've deleted a whole bunch of young objects just by not copying them. But once it's in the old generation, you run right into the same issue with fragmentation and having to keep track of where deleted objects are so you can reuse that space. If the idea is that you just keep doing memcopies for all the live objects to reuse the space and avoid looking at dead objects, I'd think that that is it's own performance issue?
cha5m 11y ago
Why is this the case?