3 ms·

What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers t

What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers the possibility of a memory leak and memory corruption.

Aloisius 13y ago
If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's policy of taking memory and rarely giving it back can cause unnecessary swapping. Heaven forbid you need to run multiple JVMs on the same machine (like with hadoop). Then you start having to do silly things like specifying how much memory your app is allowed to use which makes me feel like I'm on classic MacOS.
- AlisdairO 13y ago
  This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).
  - levosmetalo 13y ago
    No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way. I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configured the app to trigger deallocation to the OS when there's more that 20% of free memory. Worked like a charm even on and old ere 1.5 Sun JVM.
    - AlisdairO 13y ago
      That mostly works, but you do still run into the issue of the memory hanging around until collection - so if your JVM doesn't choose to collect (because it has a high Xmx set), it keeps a bunch of ram.
aufreak3 13y ago
The memory tax for GCed language was written up in [1]. The blog post [2] (which is a great read that I recommend) summarized it like this - "As long as you have about 6 times as much memory as you really need, you’re fine. But woe betide you if you have less than 4x the required memory." [1] http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf [2] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

Aloisius 13y ago

If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's policy of taking memory and rarely giving it back can cause unnecessary swapping. Heaven forbid you need to run multiple JVMs on the same machine (like with hadoop). Then you start having to do silly things like specifying how much memory your app is allowed to use which makes me feel like I'm on classic MacOS.

AlisdairO 13y ago
This is a big issue for me too. IIRC the next version of the JVM will allow you to specify a target memory usage as well as a max, which will encourage it to GC more after memory spikes. You should be able to return some of this to the system without too much penalty (as long as the spikes aren't too frequent...).
- levosmetalo 13y ago
  No need to wait for the "next gen" GC. Right now you can specify min percentage of free space in a heap that triggers giving back memory to the OS. Yes, you need to specify a few more GC parameters, but it's certainly doable to force JVM to behave this way. I used this approach in the past to keep memory usage lean. I had some spikes in application that required a lot of memory, so had to keep Xmx high, but configured the app to trigger deallocation to the OS when there's more that 20% of free memory. Worked like a charm even on and old ere 1.5 Sun JVM.
  - AlisdairO 13y ago
    That mostly works, but you do still run into the issue of the memory hanging around until collection - so if your JVM doesn't choose to collect (because it has a high Xmx set), it keeps a bunch of ram.

aufreak3 13y ago

The memory tax for GCed language was written up in [1]. The blog post [2] (which is a great read that I recommend) summarized it like this - "As long as you have about 6 times as much memory as you really need, you’re fine. But woe betide you if you have less than 4x the required memory." [1] http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf [2] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...