3 ms·

The Android phones appeared a year or so later. Memory prices weren't the same. And GC is always less efficient than no GC, even with more memory.

tomjen3 15y ago
Not necessarily. Especially not if you can program the cache (no idea if that is possible on an ARM processor). The thing is that Malloc isn't particularly smart about how memory is allocated so you can end up with various tangles, etc. On the other hand if you have enough memory you can do a hole world copy which, among other things, means that allocating memory is O(1). This is better than malloc if you have short lived and small objects.
- bitwize 15y ago
  That's what custom allocators in C++ are for. If your available memory is less than five times the working-set size, GC is less efficient than some sort of malloc/free perhaps with reference counting
  - dpark 15y ago
    Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.
    - bitwize 15y ago
      Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9682 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9... The reference counting would only be used in certain cases where the dynamic extent of the object is unknown. Most objects can be cleaned up with an implicit management scheme like the RAII pattern in C++.
      - dpark 15y ago
        Thanks. I'll take a look at that.
dpark 15y ago
> And GC is always less efficient than no GC, even with more memory. No, it's not. GC allows for more efficiency in many scenarios. Imagine creating and destroying many small objects. With traditional memory management, every malloc incurs a cost to allocate a chunk of memory from the free store. This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. On the other hand, in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested. Depending on the scenario, GC can be just as fast, or even faster. In other scenarios, manual memory management may be faster.
- dextorious 15y ago
  > This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior. > in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested. Sure, but by "less efficient" I'm not only referring to allocation speed, but also to memory usage. That nursery pool is auto-managed, and not program specific (with the exception of some smart gc guesses).
  - dpark 15y ago
    No, the work I described is not done by the typical developer. When's the last time you coded your own malloc ? Under the covers, though, malloc has to a lot of expensive bookkeeping of the sort I described that modern GC doesn't have to worry about. And GC can be more efficient in terms of memory usage as well. Modern GCs compact and so avoid most loss due to fragmentation. Where malloc will generally leave blocks partially unused, GC can allocate objects consecutively with no space between them, even if the objects vary in size (though there may be loss due to alignment, but that loss will occur in any memory management scheme).

tomjen3 15y ago

Not necessarily. Especially not if you can program the cache (no idea if that is possible on an ARM processor). The thing is that Malloc isn't particularly smart about how memory is allocated so you can end up with various tangles, etc. On the other hand if you have enough memory you can do a hole world copy which, among other things, means that allocating memory is O(1). This is better than malloc if you have short lived and small objects.

bitwize 15y ago
That's what custom allocators in C++ are for. If your available memory is less than five times the working-set size, GC is less efficient than some sort of malloc/free perhaps with reference counting
- dpark 15y ago
  Where did you get this 5x number? As for reference counting, that's rather time-expensive, and does horrible things to the cache in multi-threaded scenarios.
  - bitwize 15y ago
    Hertz and Berger's "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9682 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.61.9... The reference counting would only be used in certain cases where the dynamic extent of the object is unknown. Most objects can be cleaned up with an implicit management scheme like the RAII pattern in C++.
    - dpark 15y ago
      Thanks. I'll take a look at that.

dpark 15y ago

> And GC is always less efficient than no GC, even with more memory. No, it's not. GC allows for more efficiency in many scenarios. Imagine creating and destroying many small objects. With traditional memory management, every malloc incurs a cost to allocate a chunk of memory from the free store. This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. On the other hand, in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested. Depending on the scenario, GC can be just as fast, or even faster. In other scenarios, manual memory management may be faster.

dextorious 15y ago
> This will involve some work to break the correct-sized piece of memory off some larger block, and some bookkeeping for later restoring that memory to the block and possibly enlarging the block, merging with others, etc. This manual work incurs a penalty only for the developer, not for the performance. And you get to fine tune your memory allocations to your program's behavior. > in a modern generational GC, a malloc typically consists of adjusting a single pointer to the nursery pool by the size requested. Sure, but by "less efficient" I'm not only referring to allocation speed, but also to memory usage. That nursery pool is auto-managed, and not program specific (with the exception of some smart gc guesses).
- dpark 15y ago
  No, the work I described is not done by the typical developer. When's the last time you coded your own malloc ? Under the covers, though, malloc has to a lot of expensive bookkeeping of the sort I described that modern GC doesn't have to worry about. And GC can be more efficient in terms of memory usage as well. Modern GCs compact and so avoid most loss due to fragmentation. Where malloc will generally leave blocks partially unused, GC can allocate objects consecutively with no space between them, even if the objects vary in size (though there may be loss due to alignment, but that loss will occur in any memory management scheme).