Dealing with the interior pointers bug

Steven Schveighoffer via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Jun 22 08:27:24 PDT 2017


On 6/21/17 1:23 PM, H. S. Teoh via Digitalmars-d-learn wrote:
> On Wed, Jun 21, 2017 at 05:11:41PM +0000, TheGag96 via Digitalmars-d-learn wrote:
>> On Wednesday, 21 June 2017 at 15:42:22 UTC, Adam D. Ruppe wrote:
>>> This comes from the fact that D's GC is conservative - if it sees
>>> something that *might* be a pointer, it assumes it *is* a pointer
>>> and thus had better not get freed.
>>
>> So is the GC then simply made to be "better-safe-than-sorry" or is
>> this a consequence of how the GC does things? Or rather, does the GC
>> know the type of any references to its memory at all?
> 
> The reason the GC must be conservative is because (1) D is a systems
> programming language, and also because (2) D interfaces directly with C.

There are actually two categories of reasons: Design and Implementation.

In the Design category, D can never have a truly precise scanning 
capability because of void * and unions. These two features would be 
impossible to determine what the actual layout of pointers for a given 
block actually is.

In the Implementation category, precise scanning (to a certain degree) 
is achievable. But the current GC treats all blocks as "every 
size_t.sizeof bytes are a pointer" or "there are no pointers". With a 
better understanding of the layout of memory, the GC could be smarter 
about scanning. However, there are costs to the complexity.

In addition, the GC does not know the stack layout of memory. So the 
stack can always create false pointers as it must be scanned 
conservatively. We could potentially create a precise map of the stack, 
but that involves either restricting the compiler from reassigning stack 
data to mean something else, or keeping a running map of what stack data 
is actually used. Both don't seem appealing to a performance-oriented 
language (system) language. Add alloca to the design category of memory 
that can't be precisely scanned as well.

So we could do better in this front, but I don't know that it will 
happen because of the performance concerns. Rainer Schuetze implemented 
a precise scanner a while back, and did a dconf talk on it. So it is 
definitely possible (to a certain degree).

-Steve


More information about the Digitalmars-d-learn mailing list