On Saturday, 27 May 2017 at 17:57:03 UTC, Mike B Johnson wrote:
And what if one isn't interfacing to C? All pointers should be known. You can't access memory by and int or any other non-pointer type! Hence, when pointers are created or ints are cast to pointers, the GC should be informed and then handle them appropriately
Eh? So *every* cast from and to a pointer should become a call into the runtime, poking the GC? Or rather, every variable declaration should somehow be made magically known to the GC without any runtime cost?
(then, instead of scanning a 100MB block of memory for "pointers" it should scan the list of possible pointers(which will generally be much much lower).
That's precisely what it does, it scans the possible suspects, nothing more. That is, the stack (it has no idea what's there, it's just a block of untyped memory), memory it itself allocated *only if* it needs to (e.g. you allocated a typed array, and the type has pointers), memory you've specifically asked it to scan. It won't scan that block of 500k ints the OP allocated, unless told to do so. It would scan it if it was a void[] block though.
Therefor, in a true D program(no outsourcing) with no pointers used, the GC should never have to scan anything.
No pointers used? No arrays, no strings, no delegates?.. That's a rather limited program. But thing is, you're right, in such a program the GC will indeed never have to scan anything. If you never allocate, GC collection never occurs either.
It seems the GC can be smarter than it is instead of just making blanket assumptions about the entire program(which rarely hold), which is generally always a poor choice when it comes to performance...
Unnecessary interaction with the GC, e.g. informing it about every cast, is a poor choice for performance.
After all, if we truly want to be safe, why not scan the entire memory of the system? Who knows, some pointer externally might be peeping in on our hello world program.
What?
