3 ms·
Yes, it's very easy to make pause times low if you're willing to make allocation expensive - it's all trade-offs. In multicore's case it's about keeping low pa
by sadiq 7y ago
Yes, it's very easy to make pause times low if you're willing to make allocation expensive - it's all trade-offs.
In multicore's case it's about keeping low pause times while also keeping allocation cheap _and_ maintaining throughput.
- chrisseaton 7y agoWhy would allocation become more expensive in parallel? Surely you’re allocating in thread-local space? It’s like two machine instructions. Where does the extra overhead come from?
- throwaway894345 7y agoIf you want conventional shared memory parallelism, then your allocations can't assume thread-locality.
- chrisseaton 7y ago> If you want conventional shared memory parallelism, then your allocations can't assume thread-locality. I don't really understand why not. Can you expand on it? Doesn't the JVM for example do thread-local allocations in a conventional shared-memory parallel environment?
- throwaway894345 7y agoI was mistaken; wasn't thinking clearly as I responded. JVM can get away with this because it's generational/moving; bump allocator works in the young generation and then objects are subsequently moved. Generational/moving is tricky, especially with C APIs (if the GC moves an object that C has a pointer to, the C code dereferencing the pointer will find potentially garbage data) and I believe they make it difficult to get good STW times, but at this point I'm pretty well out of my depth.
- sadiq 7y agoBoth current multicore GCs do exactly that to keep allocation cheap but there are different design choices within the constraints we could have gone with. To avoid frequent synchronisation we could have gone with a (potentially generational) non-moving collector for the minor GC which would still have preserved the C API, probably allowed for very low pauses but would have made allocation more expensive.