5 ms·

For a short lived Java process you can use the no-op garbage collector (ie don't collect). http://openjdk.java.net/jeps/318 http://openjdk.java.net/jeps/318

by ape4 7y ago

MaxBarraclough 7y ago
That would save the trouble of initializing a garbage collector that isn't going to be used. Is that a significant saving?
- jillesvangurp 7y ago
  Initializing a GC has almost no overhead (compared to e.g. loading some classes). The only reason to introduce this is to intentionally avoid overhead for having it actually reclaim memory under the assumption that it is in any case not going to ask for more than there is. This does not make sense for long running servers but could make sense for short running things like lambda functions, command line stuff etc. Of course if this overhead is substantial that probably means this is not a good solution since you apparently have a lot of memory allocation happening.
- stygiansonic 7y ago
  “Last-drop throughput improvements. Even for non-allocating workloads, the choice of GC means choosing the set of GC barriers that the workload has to use, even if no GC cycle actually happens. All OpenJDK GCs are generational (with the notable exceptions of non-mainline Shenandoah and ZGC), and they emit at least one reference write barrier. Avoiding this barrier can bring the last bit of throughput improvement. There are locality caveats to this, see below.” From: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
  - MaxBarraclough 7y ago
    I'd missed that, thanks.
- chrisseaton 7y ago
  > That would save the trouble of initializing a garbage collector that isn't going to be used. It also saves evacuating thread-local allocation spaces and running all the barriers.
andreareina 7y ago
"git is a really great set of commands, and it does things like malloc(); malloc(); malloc(); exit();"[1] [1] https://youtu.be/dBSHLb1B8sw?t=113 https://youtu.be/dBSHLb1B8sw?t=113
- cpeterso 7y ago
  I heard that gcc didn't free() memory because compilation speed is important and the compiler process was expected to be short-lived. I don't know if that is (still) true, but it sounds reasonable to me.
  - ben-schaaf 7y ago
    D doesn't do this (there's a flag now, not sure how well it works), if you've got a lot of compile time functions running the compiler process will rack up GBs of memory pretty quickly, especially if you're compiling in parallel. I upgraded to 32GB of RAM so I wouldn't hit swap when compiling.

For a short lived Java process you can use the no-op garbage collector (ie don't collect). http://openjdk.java.net/jeps/318 http://openjdk.java.net/jeps/318

by ape4 7y ago

For a short lived Java process you can use the no-op garbage collector (ie don't collect). http://openjdk.java.net/jeps/318 http://openjdk.java.net/jeps/318

MaxBarraclough 7y ago

That would save the trouble of initializing a garbage collector that isn't going to be used. Is that a significant saving?

jillesvangurp 7y ago
Initializing a GC has almost no overhead (compared to e.g. loading some classes). The only reason to introduce this is to intentionally avoid overhead for having it actually reclaim memory under the assumption that it is in any case not going to ask for more than there is. This does not make sense for long running servers but could make sense for short running things like lambda functions, command line stuff etc. Of course if this overhead is substantial that probably means this is not a good solution since you apparently have a lot of memory allocation happening.
stygiansonic 7y ago
“Last-drop throughput improvements. Even for non-allocating workloads, the choice of GC means choosing the set of GC barriers that the workload has to use, even if no GC cycle actually happens. All OpenJDK GCs are generational (with the notable exceptions of non-mainline Shenandoah and ZGC), and they emit at least one reference write barrier. Avoiding this barrier can bring the last bit of throughput improvement. There are locality caveats to this, see below.” From: https://openjdk.java.net/jeps/318 https://openjdk.java.net/jeps/318
- MaxBarraclough 7y ago
  I'd missed that, thanks.
chrisseaton 7y ago
> That would save the trouble of initializing a garbage collector that isn't going to be used. It also saves evacuating thread-local allocation spaces and running all the barriers.

andreareina 7y ago

"git is a really great set of commands, and it does things like malloc(); malloc(); malloc(); exit();"[1] [1] https://youtu.be/dBSHLb1B8sw?t=113 https://youtu.be/dBSHLb1B8sw?t=113

cpeterso 7y ago
I heard that gcc didn't free() memory because compilation speed is important and the compiler process was expected to be short-lived. I don't know if that is (still) true, but it sounds reasonable to me.
- ben-schaaf 7y ago
  D doesn't do this (there's a flag now, not sure how well it works), if you've got a lot of compile time functions running the compiler process will rack up GBs of memory pretty quickly, especially if you're compiling in parallel. I upgraded to 32GB of RAM so I wouldn't hit swap when compiling.