Has vibe.d been tried out with a different GC that doesn't stop the world? Or at least stops it for much less time. I noticed this:
http://dconf.org/2013/talks/lucarella.html
On 2017-05-10 02:12, Carl Sturtivant wrote:
Has vibe.d been tried out with a different GC that doesn't stop the world? Or at least stops it for much less time. I noticed this:
http://dconf.org/2013/talks/lucarella.html
IIRC, that GC is for D1 only. There was some attempt to convert it to D2
but has not progressed much. It's also limited to Linux only, but I
guess it's on Linux one would most likely run something production.
/Jacob Carlborg
On Wed, 10 May 2017 00:12:18 GMT, Carl Sturtivant wrote:
Has vibe.d been tried out with a different GC that doesn't stop the world? Or at least stops it for much less time. I noticed this:
http://dconf.org/2013/talks/lucarella.html
Just mentioning it for completeness sake - one thing that helps reducing the impact of the stop-the-world approach is to use the multiple process approach, where each identical process listens on the same port using the reusePort option. That way, at least n-1 out of n processes will continue to run and continue to accept incoming connections while a single one is in a collection phase.
But in general, the only thing that really helps (because for a concurrent GC, memory will soon become an issue) is to avoid GC allocations or dynamic allocations in general as much as possible. The vibe.web package is not quite there yet, but the goal is to eliminate all dynamic allocations there eventually. This would then leave just the application logic itself for a typical web application.
On Tue, 30 May 2017 15:47:14 GMT, Sönke Ludwig wrote:
But in general, the only thing that really helps (because for a concurrent GC, memory will soon become an issue) is to avoid GC allocations or dynamic allocations in general as much as possible. The
vibe.webpackage is not quite there yet, but the goal is to eliminate all dynamic allocations there eventually. This would then leave just the application logic itself for a typical web application.
That would be nice. For a web server the bump the pointer allocation strategy at least sounds like a perfect fit. Since most allocation will be request local and at the end of a request it can just reset the pointer and reuse the memory. Although the fibers complicated this a bit.