[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