The Trunk: System-nice.777.mcz

What I mean is that if the system needs to know the endianness if the segment after it has been loaded I don't see any problem with simply checking the endianness of the segment before loading it and remembered by the result in a variable.

I get the need to have the tests pass by deleting an unnecessary test.

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

> On Nov 11, 2015, at 8:35 PM, Eliot Miranda <[hidden email]> wrote:
>
> Hi David,
>
>>> On Nov 11, 2015, at 8:07 PM, David T. Lewis <[hidden email]> wrote:
>>>
>>> On Wed, Nov 11, 2015 at 03:07:30PM +0000, [hidden email] 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)