[Vm-dev] Re: A question about #become: (was: Re: [squeak-dev] [ANN] Squeak 5)

Eliot Miranda eliot.miranda at gmail.com
Wed Aug 12 19:03:12 UTC 2015

On Wed, Aug 12, 2015 at 11:58 AM, Eliot Miranda <eliot.miranda at gmail.com>

> On Wed, Aug 12, 2015 at 11:57 AM, tim Rowledge <tim at rowledge.org> wrote:
>> On 12-08-2015, at 11:20 AM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> >
>> >
>> > On Wed, Aug 12, 2015 at 11:09 AM, Levente Uzonyi <leves at elte.hu> wrote:
>> > I wonder if you're creating two forwarders in case of #become:, with
>> objects of different size, or just one forwarder for the larger object
>> while copying the smaller object over the larger one (when possible).
>> >
>> > Right now it's the simplest thing that could possibly work.  I think
>> this is a great idea though.  It would potentially eliminate the
>> post-become stack scan if all objects can be becomed either by exchanging
>> contents or (in one-way) shortening.  Alas I don't have time for this right
>> now.  Any volunteers interested?
>> Huh; I thought you had done that ages ago. I recall suggesting it really
>> early in your spur work and could have sworn you did it right then.
> I think I did exchange of contents when the objects are of the same size,
> at your prompting, but I definitely know I /didn't/ do shortening in
> one-way as per Levente's suggestion.
> _,,,^..^,,,_

Note that there are a fair few potential cases to cover here.  An object
may be the last object in eden, or the survivor spaces and may have room
beyond it to lengthen it, so it could become a larger object by stretching
and copying.  It may be in old space and followed by a free object and so
again be amenable to stretching.  I suggest that someone collect data on
how often shrinking and/or stretching is an option before expending effort

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150812/e26f5c10/attachment-0001.htm

More information about the Vm-dev mailing list