[squeak-dev] The Trunk: System-nice.777.mcz

Eliot Miranda eliot.miranda at gmail.com
Thu Nov 12 04:35:58 UTC 2015


Hi David,

> On Nov 11, 2015, at 8:07 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> 
>> On Wed, Nov 11, 2015 at 03:07:30PM +0000, commits at source.squeak.org wrote:
>> Nicolas Cellier uploaded a new version of System to project The Trunk:
>> http://source.squeak.org/trunk/System-nice.777.mcz
>> 
>> ==================== Summary ====================
>> 
>> Name: System-nice.777
>> Author: nice
>> Time: 11 November 2015, 4:07:14.754 pm
>> UUID: 86751135-3a70-41f9-aad1-e9de96bf1c70
>> Ancestors: System-nice.776
>> 
>> Let ImageSegment tests pass on Spur by fixing the erroneous endianness check.
>> 
>> Details:
>> 
>> In spur, primitive 98 which load an ImageSegment does become: the WordArrayForSegment segment into an Array. So all information about endianness is lost at this stage.
>> 
>> I don't know if the primitive will handle all kind of endianness, but it will eventually fail if it can't, and we won't get down to here, so the very best thing is to assume that endianness problems are already solved.

The primitive handles endianness reversals.  But endianness can be checked before invoking the primitive, so I don't understand what the problem is here, if any.


> Is this issue related to the Spur object format, or is it due to the
> implementation of primitive 98 in the VM?

It's to do with the fact that Sour doesn't provide object ordering.  The old VM allocated objects strictly ascending in memory, compacting objects down when GCing, but preserving order.  Sour provides a much more efficient scavenging GC and an idiosyncratic compaction algorithm in old space, neither of which preserve object ordering.

Once a segment is loaded, the objects in the segment need to be visited to send them post load messages so they can I thaw themselves correctly.  In the old system the objects could be enumerated by starting with the truncated image segment object left behind after turning its contents into objects because it occurs immediately before the objects in the segment.  Allocating an object immediately after creating the segment word array provides an end marker.

This just won't work in Spur.  Very large objects get allocated in old space, so there's no way to construct reliably an end marker, and if the GC runs objects may be reordered anyway.  So I chose to have the primitive become the segment word array into an array of all the objects in the segment iff the load succeeds.  It is then trivial to enumerate the loaded objects.

I *could* have implemented a different original motive that answered the set of loaded objects some other way, but the way it is now caused the least disruption.

I'm still interested in understanding what the endianness related issue is.  Anyone care to enlighten me?


> I am experimenting with tracking
> trunk changes in a 4.6 image, and I'm trying to understand if this change
> would be appropriate for a "trunk" image in the old V3 image format. I
> think the answer is no, but I'm not sure so better to ask.
> 
> Thanks,
> Dave


_,,,^..^,,,_ (phone)


More information about the Squeak-dev mailing list