Its possible but the whole idea behind a bump pointer is that new objects are allocated really fast.
You cant really put all the headers in the page because when you copy the object to a diffirent page you normally copy the header with it , putting it in 2 places makes it more expensive to move objects.. That said CLR uses a scheme called a sync block as an additional header which is an index into a global array by default its 0 (empty) but when you do a gethashcode or a lock( this) it uses the next free slot and stores it in the object header ( and a few other things like a pointer back to the object).. Moving the object is fine because its an index and if an object doesnt use hashcode / lock(this) then there is no cost. Maybe internal headers can be stored there with a next pointer for other internal references in the same object. Ben On Thu, Oct 31, 2013 at 12:51 PM, Rob Earhart <[email protected]> wrote: > On Tue, Oct 29, 2013 at 11:02 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> Identifying interior object references in large object space is easy, >> because they won't point at the start of a page. >> > > ... > > >> So the real problem is to *identify* interior references into the >> nursery or the general heap. >> > > Just curious -- presumably the nursery and general heap are for objects > less than a page? 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.) > > (... 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. > Or they could go in separate pages, if you don't need them in the mutator.) > > )Rob > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
