[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