4 ms·
Java would be disqualified due to GC: > It is worth noting that Go came nearest disqualifying itself entirely here. If it were not possible to lock out Go’s GC
by osi 10y ago
Java would be disqualified due to GC:
> It is worth noting that Go came nearest disqualifying itself entirely here. If it were not possible to lock out Go’s GC in critical regions Rust would win by default.
- jondumbau 10y agoWhat technique is used to lock the GC out?
- osi 10y agodunno- just copying what was in the original article :)
- baq 10y agoi'd guess a negative arg passed to https://golang.org/pkg/runtime/debug/#SetGCPercent https://golang.org/pkg/runtime/debug/#SetGCPercent
- cafxx 10y agoI hope not, because this way a critical section requires two non-concurrent GCs (SetGCPercent calls runtime.GC() [1] and runtime.GC() triggers a non-concurrent GC [2]). If this is the option, I hope the critical sections in ntpsec are few and far apart... [1] https://golang.org/src/runtime/debug/garbage.go?s=3706:3740#L87 https://golang.org/src/runtime/debug/garbage.go?s=3706:3740#... [2] https://golang.org/src/runtime/mgc.go?s=33685:33694#L844 https://golang.org/src/runtime/mgc.go?s=33685:33694#L844
- mike_hearn 10y agoI think the assumption is that, as ntpsec is "soft real time" i.e. not hard real time, sufficiently low pauses mean you wouldn't need to lock out the GC at all. I mean, technically anything the system or runtime does on your behalf can be thought of as a 'pause'. What if you lose your timeslice half way through a function?