what to do with postblit on the heap?

Michel Fortin michel.fortin at michelf.com
Mon Jun 20 18:59:49 PDT 2011


On 2011-06-20 18:12:11 -0400, "Steven Schveighoffer" 
<schveiguy at yahoo.com> said:

> On Mon, 20 Jun 2011 16:45:44 -0400, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> My feeling is that array appending and array assignment should be  
>> considered a compiler issue first and foremost. The compiler needs to 
>> be  fixed, and once that's done the runtime will need to be updated 
>> anyway  to match the changes in the compiler. Your proposed fix for 
>> array  assignment is a good start for when the compiler will provide 
>> the  necessary info to the runtime, but applying it at this time will 
>> just  fix some cases by breaking a few others: net improvement zero.
> 
> BTW, I now feel that your request to make a distinction between move 
> and  copy is not required.  The compiler currently calls the destructor 
> of  temporaries, so it should also call postblit.  I don't think it can 
> make  the distinction between array appending and simply calling some 
> other  function.

Well, if

	a ~= S();

does result in a temporary which get copied and then destroyed, why 
have move semantics at all? Move semantics are not just an 
optimization, they actually change the semantics. If you have a struct 
with a @disabled postblit, should it still be appendable?


> If the issue of array assignment is fixed, do you think it's worth 
> putting  the change in, and then filing a bug against the GC?  I still 
> think the  current cases that "work" are fundamentally broken anyways.

That depends. I'm not too sure currently whether the S destructor is 
called for this code:

	a ~= S();

If the compiler currently calls the destructor on the temporary S 
struct, then your patch is actually a fix because it balances 
constructors and destructors correctly for the appending part (the bug 
is then that compiler should use move semantics but is using copy 
instead). If it doesn't call the destructor then your patch does 
introduce a bug for this case.

All in all, I don't think it's important enough to justify we waste 
hours debating in what order we should fix those bugs. Do what you 
think is right. If it becomes a problem or it introduces a bug here or 
there, we'll adjust, at worse that means a revert of your commit.


>> As for the issue that destructors aren't called for arrays on the heap, 
>>  it's a serious problem. But it's also a separate problem that concerns 
>>  purely the runtime, as far as I am aware of. Is there someone working 
>> on  it?
> 
> I think we need precise scanning to get a complete solution.  Another  
> option is to increase the information the array runtime stores in the  
> memory block (currently it only stores the "used" length) and then hook 
>  the GC to call the dtors.  This might be a quick fix that doesn't 
> require  precise scanning, but it also fixes the most common case of 
> allocating a  single struct or an array of structs on the heap.

The GC calling the destructor doesn't require precise scanning. 
Although it's true that both problems require adding type information 
to memory blocks, beyond that requirement they're both independent. 
It'd be really nice if struct destructors were called correctly.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list