Creating new context classes for Exupery

Bryce Kampjes bryce at
Sun Nov 13 17:40:21 UTC 2005

I've just started work on compiling blocks but unfortunately there
isn't a spare slot in BlockContexts to hold a pointer to the natively
compiled code so I'm thinking about creating context classes for

The new contexts will be removed when Exupery is shutdown or Exupery's
code cache is initialised because they will hold pointers to compiled
code which isn't saved with the image.

However they will need a compact class number so they can be checked
for. This is important because the GC needs to check if an object is a
context so it can deal with the stack. If I use a compact class then
the extra check will just be an extra integer comparison.

I'll probably swap the position of the caller and the instruction
pointer for Exupery's contexts.  This way an integer check of either
position will indicate if it's an Exupery compiled context or an
interpreted context. Exupery's instruction pointers are pointers to
compiled code tagged as integers. The caller or sender slot should
always be a pointer object not a SmallInteger while both Exupery
instruction pointers and interpreted instruction pointers are always

Would checking the instruction pointers size be more sensible? In
practise it would be safe but there's a risk that the code cache might
be allocated at memory location 0 on some platforms.

I'll need to use my own contexts for natively compiled methods as well
once Exupery starts inlining methods. This is so that image level code
will be able to hide the inlining or de-inline if necessary (say when
single stepping in the debugger).

Any objections?


More information about the Vm-dev mailing list