On 2012-03-22, at 17:26, Eliot Miranda wrote:
>
>
> On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobr...@gmail.com> wrote:
>
> On 2012-03-22, at 15:06, Stefan Marr wrote:
>
> >
> > On 22 Mar 2012, at 14:45, Camillo Bruni wrote:
> >
> >> let's have some fun and do
> >>
> >> Object subclass: #Behavior
> >> uses: TPureBehavior
> >> instanceVariableNames: 'superclass methodDict format layout'
> >> classVariableNames: 'ObsoleteSubclasses'
> >> poolDictionaries: ''
> >> category: 'Kernel-Classes'
> >>
> >> proceed over the several warnings not to change Behavior and BOOM! :D
> >
> > Check classNameIndex and thisClassIndex in the VM implementation.
> > They are typically the hardcoded indices into the expected object layout of
> > Class objects.
> >
> > And you just changed the layout -> BOOM! magic ;)
> >
> > I don't know how much overhead it is to examine such kind of indices
> > dynamically, but we do deduce indices based on inst var names to be able to
> > support the different object layouts.
> > For my stuff, I do that at VM startup, which would not help you.
>
> They would be expensive to recompute all the time (they're used in debug
> printing). But they're not expensive to compute. So they could be recomputed
> easily. See below.
>
>
> > David did it dynamically for the Process class and checked the object
> > identity of the class I think, to know when to update the index table after
> > a layout change.
>
> right. I guess I will have to move it to some further position...
> although I have an old image with:
>
> Behavior subclass: #ClassDescription
> layout: PointerLayout
> uses: TClassAndTraitDescription
> slots: {
> #instanceVariables => Slot.
> #organization => Slot.
> #layout => Slot.
> }
> classSlots: {}
> globals: ''
> category: #'Kernel-Classes'
>
>
> which works under said Cog version :/. I guess I will just have to find some
> older VM which will support the changes
>
> I think we should make the VM work for this. classNameIndex and
> thisClassIndex should only be used for debug printing, at least thats my
> intent, and it would be possible to flush them and recompute them as a
> side-effect of e.g. a flushCache primitive.
>
> Camilo, would you create a reproducible case for me, an image that applies
> this change at start-up? Thanks.
>
> Also, can we please get into the habit of cc'ing vm-dev for issues that touch
> on the VM? I ask this so that subsequent searching for VM issues can be
> confined to a search of vm-dev archives. Again AdvThanksance.
Submitted a bug report here:
http://code.google.com/p/cog/issues/detail?id=76
the attached *.st files fail under Cog / StackVM. It would be indeed nice if
they would work.
best
cami
