[Vm-dev] Compact classes not in the compact array

[Eliot Miranda]

On Fri, Apr 6, 2012 at 10:53 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 6 April 2012 19:26, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > On Fri, Apr 6, 2012 at 9:45 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >>
> >> On 6 April 2012 18:37, Hans-Martin Mosner <hmm at heeg.de> wrote:
> >> >
> >> > Am 06.04.2012 16:41, schrieb Guillermo Polito:
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Hi!
> >> >
> >> > I was wandering what are the implications of a class being compact or
> not.
> >> > And also what happens if a class has it's format thinking it's
> compact but
> >> > it's not in the compact classes array?
> >> >
> >> > I'm looking at the implications of bootstrapping a smalltalk inside
> the
> >> > same environment, and having two CompiledMethod classes, two Array
> classes,
> >> > etc, brings me to this issue :).
> >> >
> >> > Thanks!
> >> > Guille
> >> >
> >> > Compact classes must be in the compact classes array so their
> instances know their correct class.
> >> > If you want to bootstrap an image inside another one, do it without
> compact classes.
> >> > You can always add them later when needed (which is somewhat
> questionable, because their space-saving advantage has a corresponding
> speed disadvantage).
> >> >
> >>
> >> yes, basically you can "convert/copy" any compact class to non-compact
> >> one. And construct a valid class object with methods etc.
> >> Everything will be fine unless you want to also create and use
> >> instances of such classes. Then you are in trouble.
> >> So, as long as you can guarantee that you don't run any code with
> >> those classes which involves instantiation,
> >>
> >> there will be no problems.
> >
> >
> > Um, no.  Only for certain classes can you freely convert between compact
> and uncompact.  The various VMs assume some classes are always compact
> (because its faster to check their class).
> >
>
> > In the Interpreter BlockContext and MethodContext must be at indices 13
> and 14.
> >
> What i meant is that you can replicate both of those i.e. create a
> uncompact BlockContext' and MethodContext'
> and can compile methods for them.. but should avoid instantiation.
>

Right.  And you can create compact versions that use unused indices in the
array, the last 15 being unused.  Then later you could post-process
rearrange compact class indices, getting rid of the old ones at the earlier
indices.


>
>
> > In the Stack and Cog VMs the following classes must be at the
> corresponding indices
> > Array at 3
> > LargeNegativeInteger at 4
> > LargePositiveInteger at 5
> > Float at 6
> > MethodContext at 14
> >
> > Further, the Stack and Cog VM determines the index of class ByteString
> at startup and uses it in debug printing, stack dump generation etc.
> >
> > If one needs to freely alter the compactClassesArray with a Stack or Cog
> VM one needs to generate a special VM where the various compact class
> indices (ClassArrayCompactIndex, et al, see ObjectMemory
> class>initializeCompactClassIndices) are zero.  This should work, but
> hasn't been tested.
> >
> >
> >>
> >> > Cheers,
> >> > Hans-Martin
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Igor Stasenko.
> >
> >
> >
> >
> > --
> > best,
> > Eliot
> >
> >
>
>
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120406/1e3da142/attachment.htm