import std.experimental.allocator.gc_allocator;

void main()
{
   //GCAllocator.instance.goodAllocSize(3000); // error
   writeln(theAllocator.goodAllocSize(3000)); // 3008, should be 4096
}

This is known info, why is it not available? Is there a reason this needs to be inaccurate? I can create a PR if desired.

-Steve

On 1/29/16 9:52 PM, Steven Schveighoffer wrote:
> import std.experimental.allocator.gc_allocator;
>
> void main()
> {
>     //GCAllocator.instance.goodAllocSize(3000); // error
>     writeln(theAllocator.goodAllocSize(3000)); // 3008, should be 4096
> }
>
> This is known info, why is it not available? Is there a reason this
> needs to be inaccurate? I can create a PR if desired.

There's no need, I just put in reasonable conservative defaults. Please do follow up - thanks! -- Andrei

On 1/30/16 12:41 PM, Andrei Alexandrescu wrote:
> On 1/29/16 9:52 PM, Steven Schveighoffer wrote:
>> import std.experimental.allocator.gc_allocator;
>>
>> void main()
>> {
>>     //GCAllocator.instance.goodAllocSize(3000); // error
>>     writeln(theAllocator.goodAllocSize(3000)); // 3008, should be 4096
>> }
>>
>> This is known info, why is it not available? Is there a reason this
>> needs to be inaccurate? I can create a PR if desired.
>
> There's no need, I just put in reasonable conservative defaults. Please
> do follow up - thanks! -- Andrei
>

OK, I'm making a PR for this.

Incidentally, you can do aligned allocation with GC (beyond just sizeof(real)). Just make sure your allocation requested is at least that many bytes (GC puts data into bins, each bin having the amount of bytes requested).

So for example, if you want a 16-byte allocation aligned to 32-bytes, just allocate 32 bytes and slice the first 16.

Followup questions:

1. How does one detect that automatic memory cleanup will occur? In GCAllocator, deallocate is implemented, so I can't tell that "no you don't need to call deallocate"

2. How does one allocate with an allocator for typed info? In other words, the GC will call the dtor, but only if it knows what type you put in there. With std.experimental.allocator, there isn't a way to do that.

3. I'm working on a library that (hopefully) takes an allocator for allocating a ubyte array for buffer space. If I use GCAllocator, this will mark the array as having pointers conservatively. It will also initialize all the data to 0 (needlessly in this case). How to do this correctly?

Thanks

-Steve

On 1/31/16 1:52 PM, Steven Schveighoffer wrote:

>
> OK, I'm making a PR for this.


https://github.com/D-Programming-Language/phobos/pull/3962

-Steve

On Sunday, 31 January 2016 at 18:52:48 UTC, Steven Schveighoffer wrote:
> 2. How does one allocate with an allocator for typed info? In other words, the GC will call the dtor, but only if it knows what type you put in there. With std.experimental.allocator, there isn't a way to do that.

std.allocator.{make, dispose} is the type-aware interface. They don't currently do anything with regards to GC, and I don't think they really can except for the simplest case where A is exactly GCAllocator. If GCAllocator is part of an allocator composition or hidden behind IAllocator I don't think `make` can do anything about it.

Maybe GCAllocator simply isn't that useful.

On Tuesday, 2 February 2016 at 05:04:00 UTC, Jakob Ovrum wrote:
> On Sunday, 31 January 2016 at 18:52:48 UTC, Steven Schveighoffer wrote:
>> 2. How does one allocate with an allocator for typed info? In other words, the GC will call the dtor, but only if it knows what type you put in there. With std.experimental.allocator, there isn't a way to do that.
>
> std.allocator.{make, dispose} is the type-aware interface. They don't currently do anything with regards to GC, and I don't think they really can except for the simplest case where A is exactly GCAllocator. If GCAllocator is part of an allocator composition or hidden behind IAllocator I don't think `make` can do anything about it.
>
> Maybe GCAllocator simply isn't that useful.

The issue of scanning is course also an issue when references to GC memory are stowed away in non-GC memory allocated with the standard allocator interface.