4 ms·
So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a diffe
by apta 7y ago
So you "only" have to make significant, error prone (by using unsafe) code changes as opposed to tuning a couple of parameters for the GC to account for a different workload? Again, this shows the superiority of the JVM here.
And the same approaches can be done in Java (e.g. self-managed off heap allocations), even more-so when they introduce value types.
- grumpydba 7y agoObject pools are really easy. Unsafe is only for extreme cases. Some cache libraries use it. You don't have to code it yourself. Yes this is better than relying on the end user/admin to tune things. It is more predictable.
- apta 7y agoManaging allocations is way more than just object pooling. The following code in golang allocates "n" on the heap: func main() { n := 1 fmt.Println(n) } Object pooling won't help here. The new GCs on the JVM have very few parameters to tune, I think Shenandoah or ZGC have only two parameters to set up, can't get much simpler.
- grumpydba 7y agoYou can pool n if it's on your hot path, can't you? Escape analysis was just rewritten, and the objective is to handle this case more gracefully.