On Wed, Nov 6, 2013 at 9:37 AM, Jonathan S. Shapiro <s...@eros-os.org>wrote:
> On Tue, Nov 5, 2013 at 3:57 PM, Ben Kloosterman <bkloo...@gmail.com>wrote: > >> >>> >>> 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. >> > > They are aligned to a 4 byte boundary. In the Coyotos case we would simply > be turning off GC entirely, since we never release storage. That would let > us eliminate the GC header entirely. In monolithic kernels that probably > wouldn't be an option. > You only need tp save 1 byte in the structure so the header has no cost since the header is not alligned. Note the default align 8 has a much higher cost here than interior references...so you do need to allow custom allign which is kind of yucky , its nice to know everything is align 8 but i supose we need it for interop anyway. . > > >> 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. >> > > Unfortunately that's not correct. They are allocated once at startup time > and then kept for the life of the system, but they aren't static. The size > of the respective arrays is a function of available physical memory. > Good point .. That said if you dont know the size you cant use an embedded array.. so you have to use a vector to hold them and hence you want pointers to vec[i]. We have discussed variable sized objects like string but its a slippery slope... > As you note, these objects are definitely "known live". > Yep so no need to ref count. I think "known live" objects are common enough that we ensure we dont emmit counting . Not sure practically of the best way to do this we can tie it to the type or use a bit . An attribute on the type maybe the best way or possibly user regions Ben
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
