[Mono-list] Making a ruby.net compiler

Miguel de Icaza miguel@ximian.com
12 May 2003 11:20:06 -0400


> 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, which I believe to be MUCH worse,
> because it involves heavy penalty cycles in most current CPUs and is even
> disallowed on some RISCs

You can pick another two bits, and just allocate objects where those two
bits are valid ;-)

> 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

This is correct at face value, but we do not know what is more
expensive: anding a pointer on each access, or testing the type of the
object.  It will depend heavily on the pattern and volume that you will
be dealing with.  testing is required in this area.

> 3. It also (may or may not) make your memory allocator be sub-optimal
> because you have to deal with an internal fragmentation (you either allocate
> contiguous block and discard the beginning of it or allocate contiguous one
> and mangle the pointer, but you have to make a decision which takes time)
> 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
> This has an interesting property of being able to make decisions by checking
> some pointer bits, keeps your pointers aligned and may even allow for the
> jump table approach.
> Just an idea.

Yes, exactly!

The bottom line (which Paolo echoed much better than I did) is: we would
love to use Mono as a test-bed for trying out different optimizations
that would help dynamic languages, a research platform if you will.

I proposed using lower two bits, you suggested an encoding that has a
lesser performance penalty, then Fergus suggested using an attribute
instead of a runtime call.  We are fleshing out the original idea to be
useful.  Through this iterative process we can polish something up. 
When the process is done, we can publish a document that others can use
to improve the performance of dynamic languages on their runtime.