On 6/6/17 8:34 AM, Stanislav Blinov wrote:
> On Tuesday, 6 June 2017 at 12:07:28 UTC, Steven Schveighoffer wrote:
>> On 6/6/17 6:36 AM, Stanislav Blinov wrote:
>>> On Tuesday, 6 June 2017 at 09:57:31 UTC, Steven Schveighoffer wrote:
>>>
>>>> No, 2 allocations instead of N.
>>>
>>> Oh, I misunderstood you. You mean two blocks total, for scanned and
>>> non-scanned data. This could indeed work for cases when more than two
>>> arrays are needed. Still, it's one extra allocation.
>>>
>>
>> True. But O(2) is better than O(N) :)
>>
>
> Heh, this isn't malloc. We could end up in a situation when even one
> allocation is slower than N, depending on when they happen :)
>
> 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.

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 :)

-Steve

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 :\

On Tuesday, 6 June 2017 at 13:29:32 UTC, Stanislav Blinov wrote:

> 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 :\

Ah, but of course I forgot to .init, never mind.