4 ms·
That would save the trouble of initializing a garbage collector that isn't going to be used. Is that a significant saving?
by 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 agoInitializing 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 agoI'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.