Discussion Thread: DIP 1028--Make @safe the Default--Final Review

[Joseph Rushton Wakeling]

On Wednesday, 1 April 2020 at 02:43:09 UTC, Steven Schveighoffer 
wrote:
> Nice and interesting writeup Joe!
>
> I might shine some light here:

Thanks! :-)

> The biggest problem in 32-bit land is that the address space is 
> so small. With a conservative GC, it treats things that aren't 
> pointers as pointers. This means that depending on where the 
> system lays out your memory, likely integers have a better 
> chance of "pinning" memory. In other words, some int on a stack 
> somewhere is actually treated as a pointer holding some piece 
> of memory from being collected. If that memory has pointers in 
> it, maybe it also has ints too. Those ints are treated as 
> pointers, so now more memory could be "caught". As your address 
> space available shrinks, the chances of having false pinnings 
> get higher, so it's a degenerative cycle.

Ah right, this was it!  I remember several different folks 
discussing that with me at some point (probably my lead and Luca, 
on different occasions).

> With 64-bit address space, typically everything is allocated 
> far away from typical long values, so the pinning is much rarer.

Right.  In fact, I think may have been part of why my lead was 
happy to let me try to relax the rules with my app.

I don't think we ever got _certainty_ that this was what had been 
impacting the older code and builds, but it was such a good 
contender that, with the problem no longer showing up (and 32-bit 
DMD long abandoned), it didn't seem worth anyone's time to dig 
deeper and prove it 100%.  But I should check in with some folks 
to confirm.  It may be that they explicitly identified the 
problem with 32-bit all those years ago, and that's why the 
strict rules were introduced in the first place.

> I'm not sure if this matches your exact problem, but I 
> definitely am sure that 64-bit D is much less likely to leak GC 
> memory than 32-bit D.

Yup.  But once practical experience showed that, we never dived 
too deep on whether the problem was really not there with 64-bit, 
or if it was just happening so slowly that it didn't matter even 
for the long-lifetime server apps.

> With the non-stomping feature, the "used" space of the array is 
> stored in the block as well (at the end of the block). This 
> allows the array runtime to know when it's safe to append 
> in-place, or when a new block has to be allocated. This is 
> actually quite necessary especially for immutable data such as 
> strings (overwriting still-accessible immutable data is 
> undefined behavior in D2).
>
> The drawback though, is that allocating an array of 16 bytes 
> really needs 17 bytes (one byte for the array length stored in 
> the block). Which actually ends up allocating a 32-byte block 
> (GC blocks come in powers of 2).

Ah, interesting!  I don't think we ever explicitly considered 
this (Dicebot might recall, as he thought about all the 
transition issues in much more depth than anyone else).  It 
certainly could have been a factor.

As I recall, apps that had really strict preallocate-and-reuse 
policies (and which added all the required `assumeSafeAppend` to 
avoid stomping prevention on reusable buffers) in general wound 
up with very similar memory usage (getting all the 
`assumeSafeAppend` in place was the tricky thing).  But likely 
for those apps the prellocated buffers were large enough that a 
1-byte addition wouldn't push them up into a larger block size.

The places where we saw a big difference tended to be apps with a 
relatively small overall memory usage, and a quite profligate 
attitude towards generating garbage.  But there were several of 
these (doing arguably quite similar things from a general design 
point of view) and fairly significant discrepancies in behaviour.

So I suspect that more than one factor was in play.  But the 
impact of stomping prevention and typeinfo on block size would 
have certainly been worth investigating if any of us had thought 
of it at the time (assuming my memory is right and we didn't:-)

Before we derail the discussion thread any more, maybe I ought to 
have a chat with a few former colleagues just to refresh 
memories, and write this up as a blog post ...