<br><br><div class="gmail_quote">On Fri, Apr 6, 2012 at 9:45 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 6 April 2012 18:37, Hans-Martin Mosner <<a href="mailto:hmm@heeg.de">hmm@heeg.de</a>> wrote:<br>
><br>
> Am 06.04.2012 16:41, schrieb Guillermo Polito:<br>
><br>
><br>
><br>
><br>
><br>
> Hi!<br>
><br>
> I was wandering what are the implications of a class being compact or not.<br>
> And also what happens if a class has it's format thinking it's compact but<br>
> it's not in the compact classes array?<br>
><br>
> I'm looking at the implications of bootstrapping a smalltalk inside the<br>
> same environment, and having two CompiledMethod classes, two Array classes,<br>
> etc, brings me to this issue :).<br>
><br>
> Thanks!<br>
> Guille<br>
><br>
> Compact classes must be in the compact classes array so their instances know their correct class.<br>
> If you want to bootstrap an image inside another one, do it without compact classes.<br>
> You can always add them later when needed (which is somewhat questionable, because their space-saving advantage has a corresponding speed disadvantage).<br>
><br>
<br>
yes, basically you can "convert/copy" any compact class to non-compact<br>
one. And construct a valid class object with methods etc.<br>
Everything will be fine unless you want to also create and use<br>
instances of such classes. Then you are in trouble.<br>
So, as long as you can guarantee that you don't run any code with<br>
those classes which involves instantiation, </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
there will be no problems.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>In the Interpreter BlockContext and MethodContext must be at indices 13 and 14.</div><div><br></div><div>In the Stack and Cog VMs the following classes must be at the corresponding indices</div><div><div>
<span class="Apple-tab-span" style="white-space:pre"> </span>Array at 3</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>LargeNegativeInteger at 4</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>LargePositiveInteger at 5</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>Float at 6</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>MethodContext at 14</div></div><div><br></div><div>Further, the Stack and Cog VM determines the index of class ByteString at startup and uses it in debug printing, stack dump generation etc.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Cheers,<br>
> Hans-Martin<br>
<font color="#888888"><br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
</font></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>