Idea: you can easily accommodate allocation of structs by wrapping them
in a class:
S * allocateStruct(S)()
{
class Classify { S payload_; }
auto result = new Classify;
return &result.payload_;
}
That works with the existing GC which knows how to collect classes.
Another, cheaper variant which assumes arrays are GCd properly:
S * allocateStruct(S)()
{
return (new S[1]).ptr;
}
Andrei
On 07/13/2010 07:21 PM, Sean Kelly wrote:
The GC is going to need a bit of an overhaul to support finalization of structs
anyway. Maybe this could be another use for the stored typeinfo.
Sent from my iPhone
On Jul 13, 2010, at 8:09 AM, Steve Schveighoffer<[email protected]> wrote:
Currently, there is a problem in the runtime which can result in very odd
behavior. Let's say you declare a class like this:
class C
{
int[1] x;
}
Now, let's say you do something like this:
auto c = new C;
auto x = c.x[];
x ~= 1;
What happens here? Well, the memory for c and c.x are on the heap, so the
block allocated by c is considered for appending, and a "length" field is looked
at, even though that length is possibly garbage. The result is that it's
extremely improbable, but possible, that the append could happen in place if
that "length" happens to be correct (thereby overwriting other members of c). I
can't even begin to construct a case which shows this is possible, and it may
not even be, but I think this needs attention.
In addition, if anyone allocates memory via GC.malloc, and then tries to append
to such memory, a similar problem occurs, because the allocation did not go
through the array allocation routine. This is more provable, but less likely to
happen (most people don't call GC.malloc). However, a place where I am most
concerned is closures, which I think call GC.malloc.
What I propose to fix this is to allocate one of the block attribute flags to
designate that a block is appendable. The odd part about it, is that the GC is
not aware of appending, so it is somewhat of a "user-defined" flag.
My question is, how should we declare the flag? I currently only defined it in
lifetime.d, outside the gc, but I'm thinking it should be defined in the GC as
well. Also, should I allocate the next bit, or one of the higher order bits?
I'm going to check in my code that defines it in lifetime.d only, and depending
on the responses to this, I'll add it to the GC definition too.
-Steve
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
