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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Nov 12 22:28:52 UTC 2015


The problem is with 2-bytes arrays (like ShortIntegerArray) which are not a
primitive format, but rather emulated-in-image with 4-bytes word-arrays...
We have to take a special swap-in-image for these arrays.

I re-read primitive loadImageSegmentFrom:outPointers: and it correctly swap
(4-bytes) word-arrays, but of course can't make any provision for
image-side-short-emulated.

So it's clear that I didn't correct correctly :( I just made the test pass
if both image segment producer and consumer agree on endianness...

Do you suggest adding an inst. var. to ImageSegment? I had the impression
that it was not lightweight to maintain compatibility in this case, but
maybe I'm wrong...



2015-11-12 5:38 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:

> 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 <eliot.miranda at gmail.com>
> wrote:
> >
> > 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)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20151112/8592c880/attachment-0001.htm


More information about the Squeak-dev mailing list