On Wed, Oct 30, 2013 at 9:51 PM, Rob Earhart <[email protected]> wrote:
> Would it be possible to have pages in those heaps start with a header > identifying the locations of objects within the page? On a system with 4k > pages and 16-byte object alignment, that burns 32 bytes, which seems > relatively affordable. (It might be useful for debugging, too.) > Something like that could definitely be done. In fact, it's a very small change to the immix heap layout. In immix, the main heap is comprised of 32K blocks made up of 128 byte lines. There is a per-line metadata byte at the beginning of the block (the metadata bytes live in the first line or two). In immix, each byte contains a count of the number of objects that begin in the corresponding line. If the object count is zero, the line is free. But there's an easy change that could be made to identify object starts. Note that objects in a 32-bit system occupy a minimum of 16 bytes (header, vTable ptr, one content word, 8 byte aligned), so you can have up to 8 objects per line. Which means you could instead use that metadata byte as a bitmap indicating object start positions. As a side effect, this would solve the problem of identifying the size of each object for scanning purposes, which would reduce the GC header to a single byte or possibly two in the general heap. The only down side to that is that you need all 8 bits, and my proposal to add a "continuation" marker bit to be used when large objects overflow would need to go elsewhere. That, or you could just go to a 16 bit per line representation of metadata. Or you could just declare that the last object in a line has to be bigger than 4 bytes, and claim the last start bit for a continuation marker. Oh. I'm an idiot. A line is continued if it's non-empty and it's first position bit is clear. So never mind. > (... and just to get the idea out there: you could put *all* the object > headers at the front of the page, especially if you only need a few bits. > You tend to need a full header for each word. The problem with moving the headers around is that this makes the inlined portion of the store barrier more complicated. Requiring more registers in that code sequence is potentially very expensive. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
