Creating new context classes for Exupery
andreas.raab at gmx.de
Wed Nov 16 10:18:04 UTC 2005
> Any objections?
Depends on what you're asking for. Reading your message, I am not sure
whether you are saying "here are some changes that I need in the VM to
work with Exupery" or whether you are saying "here are some design
decisions that I need to make at a point in the near future, please let
me know what you think". The point being that your message is unclear
whether you are planning to implement entirely *new* context classes
(which would interoperate somehow with what's there already) or whether
you are looking at making the existing VM deal with a *change* to the
Depending on which my answers would be vastly different: If the first
(you're writing this from scratch) I think what you're proposing sounds
generally good and I don't see any big issues off hand. If the latter,
well that would be a different story, and we would need to look very
hard at a variety of issues, including backward compatibility,
interoperability issues (like the work on closures that is still
pending), the general cost-benefit ratio etc. At least if you mean this
to be for inclusion in "production releases" instead of some special
purpose Exupery VMs (which would be fine too, and probably the best way
of developing it).
Please clarify what kind of feedback you'd like to get here.
Bryce Kampjes wrote:
> 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