<div dir="ltr">Hi,<div><br></div><div>In the interpreter VM, contexts are recycled and you have 2 pools of contexts, one for each size. Contexts represent 30% of allocations in that VM. </div><div><br></div><div>In the Stack and Cog VM, the size is used to detect stack page overflow and to allocate contexts, we could use a precise value instead of this bit flag. Using a single bit saves memory as you need 1 bit per compiled method instead of 1 byte (or even 1 word !).</div><div><br></div><div>Cheers</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 1:02 PM, Max Leske <span dir="ltr">&lt;<a href="mailto:maxleske@gmail.com" target="_blank">maxleske@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi,<br>
<br>
I’ve been looking at the code that creates new method contexts (in the image and in the VM) and I can’t figure out why it would be beneficial to fix the size of the context to (currently) 16 (22) or 56 (62) bytes. Clément says in one of his blog entries that this if for performance reasons but I don’t see where the performance gain is (the Bluebook doesn’t mention this either). At allocation time the VM simply takes the number of bytes to allocate from the “large context flag”. Maybe the performance gain comes from the idea that the size does not have to be calculated? But then I ask: why not simply store the frame size instead of this weird flag?<br>
<br>
Cheers,<br>
Max</blockquote></div><br></div>