[Mono-list] Making a ruby.net compiler
Mon, 12 May 2003 17:09:52 +1000
On 12-May-2003, Jaroslaw Kowalski <firstname.lastname@example.org> wrote:
> Some thoughts about using lowest bits of a pointer to store some flags about
> object type. I'm not sure if this is valid for this case (I'm not very good
> in functional languages)
> 1. It makes your pointers unaligned,
Not at all. The tagged pointers may be unaligned, but you subtract
(or mask out) the tag before dereferencing them. The objects that they
point to are aligned.
> 2. If you want to align your pointers before each dereference - you can do
> it but you have to add some additional instructions to the JIT output, which
> would reduce the benefit of using bit flags
Yes, there will be some overhead, but it is still worth it.
The overheads are very small, and you can reduce data space usage
dramatically using this technique, which can also improve speed
due to better locality.
> 3. It also (may or may not) make your memory allocator be sub-optimal
> because you have to deal with an internal fragmentation
No, the objects pointed to are aligned, it's only the tagged pointers
that are unaligned. So internal fragmentation is not a problem.
> I wonder if you could have separate heaps (perhaps starting at some
> well-known virtual memory addresses, like
> 0x40000000 - 0x7fffffff - heap for normal objects
> 0x80000000 - 0x8fffffff - heap for A objects
> 0x90000000 - 0x9fffffff - heap for B objects
Yes, that is a possibility. Or alternatively, you can restrict the heap
and stack to particular areas, e.g. 0x00000000-0x40000000, and use the
remaining bits as tag bits. Generally putting tags on the low bits
is simpler, more efficient, and more portable, but putting tags on the
high bits helps for cases where you need more than tags than will fit in
the low bits.
Fergus Henderson <email@example.com> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.