On Tue, Nov 5, 2013 at 8:50 PM, Ben Kloosterman <[email protected]> wrote:
> On Wed, Nov 6, 2013 at 9:37 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> On Tue, Nov 5, 2013 at 3:57 PM, Ben Kloosterman <[email protected]>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. > Yeah, but these kinds of structures tend to be hand-packed already, often without *any* room to spare. More importantly, they almost always have requirements on what appears in the first word. So you might find that byte, but not be able to get it where you need it. As I say, we're not running GC in the kernel in any case. For other codes that use internal link structures, I definitely agree that 1 byte is better than 1 word. > 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. . > I'm not clear why you say that. Perhaps that's because I'm coming from a C perspective, where we take "malloc returns an 8 byte aligned result" for granted. When something is your baseline, you don't tend to see it as a cost. But yeah, anything that increases the alignment quanta definitely has a cost. > > >> >> >>> 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. > Correct. In this case I'd allocate them as a variable vector of unboxed structures, and then use interior pointers to the actual structures. More realistically, in this case, I'd just build a custom storage manager and not screw around with the array/vector issue at all. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
