[Vm-dev] Re: Limit of the #become:

Igor Stasenko siguctua at gmail.com
Wed Apr 4 18:14:10 UTC 2012


On 4 April 2012 19:14, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Wed, Apr 4, 2012 at 8:55 AM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>>
>>
>>
>>
>> On Wed, Apr 4, 2012 at 5:32 PM, Mariano Martinez Peck <marianopeck at gmail.com> wrote:
>>>
>>> Hi guys. I noticed that there is a limit in the number of objects you can become. In my case, I am becoming 2312157 objects. So..I don't expect that the become works. I imagine that it was not designed for so many objects in mind ;)
>>> However, what I would really understand is where is the limitation and the reason.
>
>
>
>
> The limitation is in the number of forwarding blocks.  For a two-way become you need N * 2 forwarding blocks.  for a become forward 1-way become you need N forwarding blocks.  Each forwarding block takes two words (a saved header word and the new location).  During forwarding each forwarded object's header is changed to a pointer to its forwarding block.  See prepareForwardingTableForBecoming:with:twoWay: & fwdTableInit:.  The number of forwarding blocks available depend on the amount of unused heap memory.   So there is no fixed limit and growing memory will lift the limit, as may doing a GC (as you yourself found).
>

i was looking at that method.. and i am quite displeased.. :)

IMO, we could simplify the forwarding table logic by changing the
primitive to take 3 arguments instead of 2

1) first array
2) second array
3) buffer for forwarding table entries (byte array)

and for backward compatibility, if primitive is run with just 2 arguments, we
could simply silently allocate new bytearray with our preferred size.

then there will be no need to do the black magic with #fwdTableInit:
as well as any other operations which involving changing the free memory.

-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list