Add goodAllocationSize to GCAllocator

[schveiguy]

GC always allocates from bins, and has very well-defined behavior here. So goodAllocSize can be implemented quite easily.

Rules:

1. If allocation size < 16, allocate 16 bytes
2. For allocations of 16 to 8192, use the power of 2 size that will hold it.
3. For allocations greater than 8192, use the multiple of 4096 that will hold it.

I had to change some other unit tests because of the assumptions made for the default implementation of IAllocator.goodAllocSize

[deadalnix]

You should probably return before the bsr here.

[schveiguy]

Updated for better bsr usage.

[JakobOvrum]

This probably doesn't jive well with the fact that the GC is pluggable at link-time, but apart from that I guess it looks good to me.

[schveiguy]

Well, it may be inaccurate. It wouldn't be catastrophic.
We could also provide a hook for this if there was a request for it.

[JakobOvrum]

I think it's fine. Maybe when this is merged we can add a comment to gc.d informing the programmer of the assumptions made in std.allocator, so the issue can be dealt with when relevant.

[MartinNowak]

The GC bins are wasting quite some space (so should the should be replaced) and it's fairly ugly to hardcode them here.

[schveiguy]

@MartinNowak GCAllocator reports basically that you will waste no space by allocating any size (it just rounds up to the next multiple of 16). I don't see the point of having this be incorrect, as there is no way to query an allocator for the actual memory size you just created.

This is not a confirmation of the implementation of the GC, it's just trying to have GCAllocator accurately report the current situation. If you think the implementation should be done in a different way, then we can fix it when it makes sense. At this point, I don't see a lot of reason to add functions to the GC to satisfy something in std.experimental.

[andralex]

Wouldn't be better to request s - (s / 2) + 1 here instead of s? That way you do make sure that the allocator gets you the extra bytes up to s.

[schveiguy]

I can probably do both :) Not that hard to add a couple lines.

One thing I was concerned about actually, is having the GC insert extra metadata (such as array used size) that would bump the size up to the next bin.

[andralex]

Yah, I agree with @MartinNowak's point but am not worried about changes. I've never heard of plugging the GC during link time, and the moment we replace the strategy in the GC, the Phobos unittests will fail prompting change.

[schveiguy]

Added additional unit test

[andralex]

Nice, thanks! Let's hope it clears the unittest :o).

[andralex]

Auto-merge toggled on