[Vm-dev] [Spur] endless recursion in forward become

Bert Freudenberg bert at freudenbergs.de
Thu Jun 23 11:11:28 UTC 2016


On Wed, Jun 22, 2016 at 10:15 PM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
> Hi Bert,
> Do you have a reproducible case for me to look at?
>

Yes, from one email ago:

       * (ByteString new: 20000000) become: (WideString new: 20000000)*

 The fix I submitted fixes your original case.  But you could try and fix
> it yourself.  If the become: is two-way and fails with out-of-memory the
> failure code should ask to grow memory by the sum of the instance byte
> sizes.
>

The failure code in *elementsExchangeIdentityWith:* asks the memory to grow
by a fixed amount and retry:

ec == #'insufficient object memory'
ifTrue: [Smalltalk garbageCollect < 1048576
ifTrue: [Smalltalk *growMemoryByAtLeast:* 1048576].
^ self elementsExchangeIdentityWith: otherArray].

After a few repetitions of this there *should* be enough room.

The problem is that *growMemoryByAtLeast:* does *not* grow the memory, it
apparently only assures that the given amount is available. If that
is indeed the intention of primitive 180, we should rename it to something
like *ensureMemoryAtLeastFree:*.

 There us a bytesSzeOfInstance: method (or close) to compute the required
> space.
>

This seems to work, yes:

ec == #'insufficient object memory' ifTrue:
[Smalltalk *ensureMemoryAtLeastFree*: ({self. otherArray} detectSum:
[:array | array detectSum:
[:obj | obj class byteSizeOfInstanceOfSize: obj basicSize]]).
^self elementsExchangeIdentityWith: otherArray].

Would renaming *growMemoryByAtLeast:* (and fixing its comment) make sense?

- Bert -

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160623/bb941d47/attachment-0001.htm


More information about the Vm-dev mailing list