On Friday, 15 January 2021 at 18:43:44 UTC, Guillaume Piolat
wrote:
Calling collect() isn't very good, it's way better to ensure
the GC heap is relatively small, hence easy to traverse.
You can use -gc=profile for this (noting that things that can't
contain pointer, such as ubyte[], scan way faster than void[])
Ok, so what you basically say is that the number of pointers to
trace was small, and perhaps also the render thread was not under
GC control?
I think it is better with something simpler like saying one GC
per thread
But then ownership doesn't cross threads, so it can be tricky
to keep object alive when they cross threads. I think that was
a problem in Nim.
What I have proposed before is to pin down objects with a ref
count when you temporarily hand them to other threads. Then the
other thread will handle it with a smart_pointer which release
the "borrow ref count" on return.
But yes, you "need" some way for other threads to borrow thread
local memory, in order to implement async services etc. Then
again, I think people who write such service frameworks will be
more advanced programmers than those that use them. So I wouldn't
say it is a big downside.
But sometimes that ownership is just not interesting. If you
are writing a hello world program, no one cares who "hello
world" string belongs to. So the GC is that global owner.
I get your viewpoint, but simple types like strings can be
handled equally well with RC... If we take the view, that you
also stressed, that it is desirable to keep the tracable pointer
count down, then maybe making only class object GC is the better
approach.
