> > > > Right now, MemHeader structures are allocated from an array. If we > switched to an array of* references* to MemHeaders, we would effectively > add a word to the cost of every MemHeader. We simply don't *have* an > additional word for these structures. >
If your header is 1 byte and you have no vtable for these objects , then the header has no cost unless the header is exactly 16 bytes. Even in an array these objects are likely to be aligned. > > What we *could *do, I suppose, is move the array notion into the > allocator and deal with it there as an unsafe operation. In a kernel that > would be okay, because it's very well localized. We need some unsafe > operations down there in any case, because that's the layer where we are > converting raw memory to object storage. > > The thing to note here, I suppose, is that that containment typing trick > doesn't work in this case. We aren't dealing with a particular, known > element. > One think is worth noting is many of these structures are static and exist for the whole life of the program .. as you keep mentioning you dont put them on a heap . This leads to a whole series of benefits - They are never moved - References to such structures need never be counted , since there is no counting there is no defered reference counting ( eg no M bit) - They will probably be in a region which exists for whole program lifeliness ( static Region ?) For GP programming such structures are avoided. Note there are whole classes of these - Objects that exist of the whole life of the program or region dont need to be counted. We should try to distinguish such objects from other objects of the same type that can live on the heap or mark them in some way that these objects only exist in a region/stack . - Objects that never exist in the nursery/ main heap ( eg only in a region , large object heap or stack) are never moved. So no forwarding - Pinned objects never move so no forwarding etc Ben
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
