Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 19:36 me escribiste:
Leandro Lucarella wrote:
Frits van Bommel, el 13 de abril a las 13:30 me escribiste:
Or you can pin anything that's referenced from the stack, and move
anything that is only referenced from the heap.
That's more likely to happen, but it requires a compiler change too
(provide type information on allocation). Maybe I wasn't too clear,
I didn't mean to say that a moving collector is impossible, what is
impossible is to make allocation a "pointer bump".
The compiler already passes a TypeInfo on allocations IIRC. And TypeInfo can
produce a TypeInfo[], it just happens that DMD and GDC don't fill it in for
user-defined aggregates, and LDC needs a compile-time #define to enable it
(because it breaks linking the Tango runtime, IIRC).
(For other types, this fact it returns null is a simple library issue)
Well, this is nice to know (even when it's not used yet, it's better than
nothing). And how can the GC obtain this kind of information?
Well, since the allocation routines should all get a TypeInfo reference
from the compiler, the GC can store the typeinfo for each memory block
somewhere, and later use it. It can then call ti->offTi() which should
return an array of OffsetTypeInfo structs (see object.d[i]). The only
caveat is that those array return values should be statically allocated;
the GC probably won't like an allocation happening during collections...
But right now gc_malloc() doesn't take any TypeInfo argument. I can't see
where I can get the TypeInfo in the first place =/
The call would have to be modified. Right now the best you can do is
pass BlkAttr.NO_SCAN. And storing a pointer per block could add a good
bit of bookkeeping overhead for small objects, of course. Perhaps the
TypeInfo array could be converted to a bitmap or some such.
