Question to GC experts: NO_SCAN for a part of the block

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 6 June 2017 at 13:05:51 UTC, Steven Schveighoffer 
wrote:

>> Actually, separate blocks might be a decent choice: there's 
>> another
>> problem with sharing blocks for different data in that 
>> finalizers can't
>> be run. So such a function would either not support types with
>> finalizers at all, or would have to allocate separate blocks 
>> for such
>> types anyway. Don't know, need to actually implement and 
>> measure if it's
>> even worth the trouble.
>
> Looking at your code, you have allocated separate blocks for 
> the objects and the bytes, but your objects still are just 
> pointers (e.g. C.sizeof == (void *).sizeof). You are allocating 
> a new block for each class instance anyway in the loop inside 
> main.

Which is exactly why I used them. The code is a short example of 
single-block array allocation, not a generic demonstration of 
intent. Classes were just an easy way to stuff pointers into an 
array while being able to see if they're being looked at by the 
GC or not. Perhaps I should've used pointers to structs, but oh 
well.

> I don't think there is any support in the GC to run the 
> finalizers of an array of class instances (read: an array of 
> class instance storage that you point at), so this whole 
> exercise may be moot if you are using classes :)

Heh, well, there is no support in the GC to *create* an array of 
class instances in the first place ;) We can, of course, do it 
manually, but that's a different story.

Structs, on the other hand, are another matter. Although, even 
creating a block with BlkAttr.FINALIZE *and* passing the struct 
typeinfo to GC.malloc() doesn't seem to compel it to run the 
struct dtors on collect, which is weird, considering it does so 
for a new'ed array of structs :\