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

[Mariano Martinez Peck]

On Wed, Apr 4, 2012 at 8:14 PM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 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.
>
>
That would be nice. Right now the workaround I did is to spit my become in
groups of say 50.000 objects. Problem is that now I need much mores memory
traversals than one ;)   And I am not 100% sure that won't crash in the
future (who knows how many free memory I will have)





> --
> Best regards,
> Igor Stasenko.
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120407/6378b35c/attachment.htm