4 ms·
In D, the GC is guaranteed to only ever run if you allocate new memory on the heap. This is still a lot of work for a video game (because you never want any la
by VHRanger 6y ago
In D, the GC is guaranteed to only ever run if you allocate new memory on the heap.
This is still a lot of work for a video game (because you never want any latency, the only way to achieve this is with an arena allocator or going full @nogc).
But for apps where the latency requirement is bounded, D doesn't make it hard and the language is nice and ergonomic.
- chrisseaton 6y ago> In D, the GC is guaranteed to only ever run if you allocate new memory on the heap. Isn't that how most GCs work? Why would you do anything else? To release memory to the OS? That's not really a priority in most runtime systems, and I think wanting to do that is a pretty niche requirement.
- frant-hartm 6y agoI want memory allocation to run in constant time, so I can achieve low latency. That's the point of concurrent GCs - they run in the background to free up memory.
- chrisseaton 6y agoI know they run in the background... but I don't think they run in the background if there's nothing to do, do they?
- imtringued 6y agoA JVM with default settings will happily allocate more memory without attempting to even run a single GC cycle until it hits the configured heap size. Once it hits the limit it will try to run the GC.
- deleted 6y ago[deleted]
- nemothekid 6y agoIn Java, everything is heap allocated, whereas in D you have a choice.
- chrisseaton 6y ago> everything is heap allocated You can definitely write useful Java applications where nothing gets heap allocated, through using existing objects, and through using scalar-replacement-of-aggregates.
- wokkel 6y agoNot entirely correct: https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacement/ https://shipilev.net/jvm/anatomy-quarks/18-scalar-replacemen... . Hoi cannot force a specific allocation, but the jit does do something akin to stack allocation.
- readittwice 6y agoReleasing memory is definitely useful for mobile devices or browsers. Even in some server use cases it's useful, e.g. when you pay for memory usage. I guess that's why the JVM has this -XX:SoftMaxHeapSize option. I guess it depends whether GCs are always scheduled in an allocation or can be triggered another way. Either way that should be easy to disable. I read somewhere that D doesn't have write barriers, so I would assume they have a hard time implementing more advanced GC features like generational collection or concurrent marking. It's not suprising that the GCs in the JVM achieve much better pause time.