You'll find a very different answer for each of the VMs. Jikes fits my intuition, as does HotSpot which is much the same, but the CLR is a surprise. Pypy is very similar to Jikes (a comparison that goes way, way beyond object layout). GNU Guile uses the low bits of the first field of the referrent to hold the type, which is quite compact, but using BDW that may not be applicable outside Guile. The javascript engines use NaN/NuN boxed pointers but I don't know about their object headers. STGs value layout is 'clever', to say the least. CPython has the pointer to the type and the refcount.
On 21 October 2013 11:39, Ben Kloosterman <[email protected]> wrote: > Just found this paper discusses this Java Object Header Elimination for > Reduced > Memory Consumption in 64-bit Virtual Machines > http://users.elis.ugent.be/~leeckhou/papers/TACO07.pdf > > There techniques have some overheads but typical speedup of 5-10% was > observed up to 20% for sparse. Along with 15-20% heap reduction (up to 38%). I'd like to say that I really like this paper, particularly because it uses the virtual memory system to remove the need to prepare the pointer for object access. And, I really like the idea of variations on a theme: Unfortunately, this example requires two different mechanisms to access the TIB - which means two different mechanisms to perform virtual method calls. It also doesn't generalise to pointers which have interface type (though this is an optimisation that none of the JVMs currently do). My intuition about reference-heavy languages is that the vtable is accessed slightly more frequently than object data itself. Nevertheless, the reduction in cache usage and the fact that it typically removes an indirection to determine the vtable pointer means it's probably a good thing overall. What are the reasons one couldn't elide an object header? Obviously the 'hashed' status can't be stored in the target, but for a language with distinct static types for pure values this may not matter. The situation for 'pinned' status is similar. I think that these can be stored in a side-table. 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? Such discussions aside, region analysis can probably remove the need for many values to be belatedly collected anyway. I think that, these things taken together, there are few objects that actually need any sort of header. There's not a lot of difficulty in treating all these different forms of references as different reference sorts when generating the code to manipulate the values, and doing that leaves me/you with a great deal of flexibility in value layout. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
