enforce()?

[Steven Schveighoffer]

On Mon, 19 Jul 2010 15:53:46 -0400, bearophile <bearophileHUGS at lycos.com>  
wrote:

> Steven Schveighoffer:
>
>> Not quite :)  There is one byte for padding because (insert  
>> gasp-inspiring
>> music accent) all struct heap allocations are allocated through newArray
>> with a size of 1.  I discovered this when working on the array append
>> patch.
>
> How much more hidden shit like this do I have to see?
> I have filed a bug report:
> http://d.puremagic.com/issues/show_bug.cgi?id=4487
> Maybe Walter has to fix this before porting dmd to 64 bits.
>
>
>> Most of this is mitigated if you have a custom allocator that allocates  
>> an
>> array of nodes at once
>
> The GC is supposed to not suck that much. If I want to do all manually  
> and use custom allocators then maybe it's better if I start to switc to  
> C language.
> Thank you Steven.

What's so horrible about it?  It's a corner case.  If you were allocating  
a 20-byte struct, you are wasting 12 bytes per value anyways.  Or what  
about a 36-byte struct?

All I'm saying is the pad byte itself isn't a huge issue, even if it  
didn't exist, there would always be inefficient allocations.  Take the  
redblack tree node for instance.  Get rid of the pad byte, and it's tuned  
for word-size payload.  But go over that, and you're back to pretty much  
wasting 50% of your memory.  If you want to tune your app to be the most  
efficient at memory allocation, you need to study the allocator and learn  
its tricks and nuances.  I think you have some misguided notion that C's  
allocator is perfect, and there's no hidden cost to it.  That's not the  
case.

That being said, it would be good if we could get rid of the 1-byte pad  
for single struct allocations on the heap.  As a bonus, the code will be  
more efficient because it doesn't have to deal with the "array" notion.

-Steve