On Thu, Oct 24, 2013 at 4:51 PM, William ML Leslie < [email protected]> wrote:
> On 24 October 2013 19:34, William ML Leslie > Besides these, the only reason to keep an object header is the obvious > - they can be used to determine the size of the value during the sweep > phase, in order to manage the free list. Is there another way we can > do that for non-typesafe heaps? > I thought there was no cheap way till i saw that paper.. I was wondering how URC can have a Nursery sweep with no header..whether they just meant GC header or Vtable as well. ( They had a main heap sorted by size but i didnt think they did it in the Nursery ) > > > 0. Accesses into an array - which can be mitigated for various > wrappers of arrays like ArrayList and String where the array field > itself is mutable, and usually of fixed type anyway. > 1. Instance methods, which can perform the mask to determine the real > 'this' in the method prelude. > > I would tend to agree with you but they did measure the performance for Java ( even cache misses) and im not one to overthrow a measurement on intuition unless i clearly know what was measured. We do have clear evidence from 4-5 papers of the significance of the header cost . Its quite possible that most (all ?) vcall objects have a header , which makes sense as they tend to be larger . The real saving of headerless is all the small infrastructure objects ( small strings , Points , Matrixes , Commands / Messages) and these are not likely to use vcalls. Even for vcall objects they shorten the pointer to 32 bits ( it can address more than 4Gb though as its a non 0 offset ) thus reducing the header . Also in a C# language these are likely to be embedded ( value) objects which will reduce the saving. Anyway best way is to build it and measure it , id be happy with just a word for the Vtable for the nursery and the same word with compressed pointer and ref counts for the main heap. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
