Context representation in current VM

> Hi Martin,
>
> On Sep 28, 2014, at 1:18 AM, Martin McClure <[hidden email]> wrote:
>
>> I'm updating the exceptions chapter of Deep Into Pharo, which currently contains this text:
>>
>> "...some Smalltalk implementations use the native C execution stack of the virtual machine to avoid creating objects all the time.
>> The current Pharo virtual machine does actually use full Smalltalk objects all the time;  for speed, it recycles old method context objects rather than creating a new one for each message-send."
>>
>> Is this still true as of Pharo 4? I'd gotten the idea that this hadn't been true for a while, that the Cog VMs that Pharo is using did use a non-object stack to cache the top N contexts, only converting to actual Context objects when necessary.
>
> So both are true; it depends on the virtual machine.  The interpreter VM works as described in the existing chapter.

> On 09/28/2014 12:20 PM, Eliot Miranda wrote:
>> Hi Martin,
>>
>> On Sep 28, 2014, at 1:18 AM, Martin McClure <[hidden email]> wrote:
>>
>>> I'm updating the exceptions chapter of Deep Into Pharo, which currently contains this text:
>>>
>>> "...some Smalltalk implementations use the native C execution stack of the virtual machine to avoid creating objects all the time.
>>> The current Pharo virtual machine does actually use full Smalltalk objects all the time;  for speed, it recycles old method context objects rather than creating a new one for each message-send."
>>>
>>> Is this still true as of Pharo 4? I'd gotten the idea that this hadn't been true for a while, that the Cog VMs that Pharo is using did use a non-object stack to cache the top N contexts, only converting to actual Context objects when necessary.
>>
>> So both are true; it depends on the virtual machine.  The interpreter VM works as described in the existing chapter.
>
> Thanks, I'd thought that was the case.
>>
>> The Cog and Stack VMs work exactly as described in my blog post on context to stack mapping.  It's not really the top N contexts.  The stack zone, which is allocated on the native stack at startup, is divided into pages, each of which can hold up to ~ 40 activations (depending on stack depth, determined by #temps and nested call complexity).  By default there are 160 pages.  That either means 160 pages full of activations of a single process (eg one that is deeply recursive) or 1 page of up to 40 activations of 160 different processes or any combination in between.  ie a page can only be used by a single process.  When a new page is needed the oldest one is emptied by ensuring  all activations on the page have contexts (on the heap), and updating the state of those contexts, effectively writing the page to the heap in the form of contexts.
>
> Ah, I'll have to reread that blog post.
>
> The remaining question is: For the purposes of this chapter, which is the default VM for Pharo 4?

> On 09/28/2014 12:20 PM, Eliot Miranda wrote:
>> Hi Martin,
>>
>> On Sep 28, 2014, at 1:18 AM, Martin McClure <[hidden email]>
>> wrote:
>>
>>> I'm updating the exceptions chapter of Deep Into Pharo, which
>>> currently contains this text:
>>>
>>> "...some Smalltalk implementations use the native C execution stack
>>> of the virtual machine to avoid creating objects all the time.
>>> The current Pharo virtual machine does actually use full Smalltalk
>>> objects all the time;  for speed, it recycles old method context
>>> objects rather than creating a new one for each message-send."
>>>
>>> Is this still true as of Pharo 4? I'd gotten the idea that this
>>> hadn't been true for a while, that the Cog VMs that Pharo is using
>>> did use a non-object stack to cache the top N contexts, only
>>> converting to actual Context objects when necessary.
>>
>> So both are true; it depends on the virtual machine.  The interpreter
>> VM works as described in the existing chapter.
>
> Thanks, I'd thought that was the case.
>>
>> The Cog and Stack VMs work exactly as described in my blog post on
>> context to stack mapping.  It's not really the top N contexts.  The
>> stack zone, which is allocated on the native stack at startup, is
>> divided into pages, each of which can hold up to ~ 40 activations
>> (depending on stack depth, determined by #temps and nested call
>> complexity).  By default there are 160 pages.  That either means 160
>> pages full of activations of a single process (eg one that is deeply
>> recursive) or 1 page of up to 40 activations of 160 different
>> processes or any combination in between.  ie a page can only be used
>> by a single process. When a new page is needed the oldest one is
>> emptied by ensuring all activations on the page have contexts (on the
>> heap), and updating the state of those contexts, effectively writing
>> the page to the heap in the form of contexts.
>
> Ah, I'll have to reread that blog post.
>
> The remaining question is: For the purposes of this chapter, which is
> the default VM for Pharo 4?
>
> Regards,
>
> -Martin
>
>