4 ms·

Collection cost in that model is irrelevant as it's only a split second and happens after hours. Yes, you can emulate a young generation in C++ or even multipl

Collection cost in that model is irrelevant as it's only a split second and happens after hours. Yes, you can emulate a young generation in C++ or even multiple young gens (i.e. arenas), obviously, as you can do anything in C++ that you can do in Java and vice-versa (java has the Unsafe class that allows you to do low level programming with pointer arithmetic etc). The question is not, can it be done, but rather what's easier and lower cost? With the Java approach, the only developer overhead is making sure you don't do too much allocation on the hot path, then sizing your young gen to avoid collections (one command line flag), and doing a GC at night. Not nothing but not too hard either; after all, you can allocate if you really need to, and some allocations will be optimised out anyway. The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. Not that different, until you screw up and try to delete something on the stack or forget to delete something that isn't. That's when the robustness the GC is giving you starts to pay off.

sandGorgon 10y ago
This is very interesting - is there any sample code one can learn from to build something in this style of programming ? Especially the deployment - do you have a scheduled that triggers GC or do you simply kill and restart, etc.
- merb 10y ago
  Actually you can trick the JVM to run a Full GC. If you run: jmap -histo:live <PID> it will show a memory map of all the live objects and since java needs to run a full GC cycle to do that it will actually run a Full GC.
CyberDildonics 10y ago
> The question is not, can it be done, but rather what's easier and lower cost? I thought it was about speed. > The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. The C++ equivalent would be to do heap allocation and never free, then shut the process down which will return its memory to the OS. Heap fragmentation wouldn't matter here since you aren't freeing any memory. Fundamentally if you can avoid freeing any memory all day then you should just allocate it up front an be done with it. Anything else is ignoring the more fundamental point that you are using a limited amount of memory and pretending that you aren't.
- sievebrain 10y ago
  Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimisations benefit your code the most. Yes you could also pre-allocate, but that's often more awkward than just allocating at the time of need, and besides, Java can turn heap allocations into not only stack allocations, but fully scalarise them (i.e. break down an allocation into a set of local variables and then delete any that are unused, move them around, etc).
  - CyberDildonics 10y ago
    > Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimizations benefit your code the most. This could not possibly be further from the truth. Getting rid of heap allocations can speed something up by ~7x. Cache locality can speed something up by 50x. Compiler optimizations do very little compared to accessing memory in a predictable way.
    - imtringued 10y ago
      Indeed! In Java or dynamic langauges you are forced to always use a reference. Which means you'll get cache misses pretty much everywhere.
viraptor 10y ago
> The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. I think that's a very brute-force approach. You could instead use an actual allocator which behaves the way you want. For example this is how arena can work without any restart/stack magic: https://github.com/cleeus/obstack/blob/master/arena_test.cpp#L186 https://github.com/cleeus/obstack/blob/master/arena_test.cpp... Same happens in google's protobufs https://developers.google.com/protocol-buffers/docs/reference/arenas https://developers.google.com/protocol-buffers/docs/referenc... There's no need (almost) for manually wiping heaps at system level if your language allows you to change the allocator at any point of the app.

sandGorgon 10y ago

This is very interesting - is there any sample code one can learn from to build something in this style of programming ? Especially the deployment - do you have a scheduled that triggers GC or do you simply kill and restart, etc.

merb 10y ago
Actually you can trick the JVM to run a Full GC. If you run: jmap -histo:live <PID> it will show a memory map of all the live objects and since java needs to run a full GC cycle to do that it will actually run a Full GC.

CyberDildonics 10y ago

> The question is not, can it be done, but rather what's easier and lower cost? I thought it was about speed. > The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. The C++ equivalent would be to do heap allocation and never free, then shut the process down which will return its memory to the OS. Heap fragmentation wouldn't matter here since you aren't freeing any memory. Fundamentally if you can avoid freeing any memory all day then you should just allocate it up front an be done with it. Anything else is ignoring the more fundamental point that you are using a limited amount of memory and pretending that you aren't.

sievebrain 10y ago
Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimisations benefit your code the most. Yes you could also pre-allocate, but that's often more awkward than just allocating at the time of need, and besides, Java can turn heap allocations into not only stack allocations, but fully scalarise them (i.e. break down an allocation into a set of local variables and then delete any that are unused, move them around, etc).
- CyberDildonics 10y ago
  > Runtime speed is, as noted, going to be similar, with the winner being determined by which compiler optimizations benefit your code the most. This could not possibly be further from the truth. Getting rid of heap allocations can speed something up by ~7x. Cache locality can speed something up by 50x. Compiler optimizations do very little compared to accessing memory in a predictable way.
  - imtringued 10y ago
    Indeed! In Java or dynamic langauges you are forced to always use a reference. Which means you'll get cache misses pretty much everywhere.

viraptor 10y ago

> The C++ equivalent would be to allocate as much as possible on the stack, and then make sure to do a restart every night to eliminate any heap fragmentation that is left. I think that's a very brute-force approach. You could instead use an actual allocator which behaves the way you want. For example this is how arena can work without any restart/stack magic: https://github.com/cleeus/obstack/blob/master/arena_test.cpp#L186 https://github.com/cleeus/obstack/blob/master/arena_test.cpp... Same happens in google's protobufs https://developers.google.com/protocol-buffers/docs/reference/arenas https://developers.google.com/protocol-buffers/docs/referenc... There's no need (almost) for manually wiping heaps at system level if your language allows you to change the allocator at any point of the app.