Smalltalk › Squeak › Squeak - Dev

A update to SystemTracer for getting back to 32 bits

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

David T. Lewis

A update to SystemTracer for getting back to 32 bits

I have been using a 64-bit (format 68002) image as my working Squeak image
for a few months now, so I became interested in the question of whether
that image could be converted back to a 32-bit image that could be run again
on Cog and on future Spur VMs. To my surprise, this turned out to be quite
easy to do.

>From the class comment from the original SystemTracer:

The SystemTracer was invented by Ted Kaehler. It has gone through many
variations. I have simplified it and adapted it to work with Squeak's
limited Object hashing. It has written runnable Mac images on a Mac.
Some changes may be needed for it to produce runnable images on a
bigEndian machine. -- Dan I. 9/29/97

The current archive is at http://www.squeaksource.com/SystemTracing

One variation of this is SystemTracer64, which is used for converting
("tracing") a standard 32-bit image into a 64-bit image format (identified
as image format 68002). An up to date trace of the Squeak image is
maintained at http://build.squeak.org/job/Squeak%2064-bit%20image/,
and a Linux VM is at
http://squeakvm.org/unix/release/Squeak-4.10.2.2614_64bit-linux_x86_64.tar.gzl

This 64-bit image (format 68002) is a straightforward extension of the
standard 32-bit image formats currently used for Squeak and Pharo (image
format 6504 or 6505). Details are in the class comment for ObjectMemory,
which now resides in package VMMaker on source.squeak.org. It provides
essentially unlimited object memory space, with minimal change to the
internal representation of the objects in that object memory. This is
not to be confused with the 64-bit Spur object memory, which provides
substantial performance improvements based on an improved (and different)
object memory design.

I made a minor update to the SystemTracer that allows it to convert a 64-bit
image back to 32-bit format, and it worked perfectly with my working Squeak
image that has been in 64-bit format for several months now.

>From the update comment:

Name: SystemTracing-dtl.26
Author: dtl
Time: 2 January 2015, 1:21:45.031 pm

Update SystemTracer2 to support tracing a 64-bit image format 68002 image
back to 32-bit image format 6504. This makes conversion to 64-bit format
a reversible process.

To trace an existing 32-bit (format 6504 or 6505) image to 64-bit format:

SystemTracer64 writeImage: 'clone64.image'

To trace an 64-bit (format 68002) image to 32-bit format:

SystemTracer2 writeImage: 'clone32.image'

The resulting 32-bit image must be opened first using an interpreter VM,
after which it can be run normally with a Cog VM. Tracing should be done
using an interpreter VM.

Dave

Bert Freudenberg

Re: A update to SystemTracer for getting back to 32 bits

On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
>
> I made a minor update to the SystemTracer that allows it to convert a 64-bit
> image back to 32-bit format, and it worked perfectly with my working Squeak
> image that has been in 64-bit format for several months now.

Nice!

> The resulting 32-bit image must be opened first using an interpreter VM,
> after which it can be run normally with a Cog VM. Tracing should be done
> using an interpreter VM.

Why is that?

- Bert -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: A update to SystemTracer for getting back to 32 bits

> On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
>>
>> I made a minor update to the SystemTracer that allows it to convert a
>> 64-bit
>> image back to 32-bit format, and it worked perfectly with my working
>> Squeak
>> image that has been in 64-bit format for several months now.
>
> Nice!
>
>> The resulting 32-bit image must be opened first using an interpreter
>> VM,
>> after which it can be run normally with a Cog VM. Tracing should be
>> done
>> using an interpreter VM.
>
> Why is that?
>

I have not yet figured out why it did not work with Cog. One possibility
is that the system is running a jitted method at the time of the trace,
and when the new 64-bit image wakes up in the interpreter VM, it is still
in the middle of that method and the VM does not know what to do with it.

That said, I also tried tracing 64 back to 32 and then running the traced
32-bit image immediately in Cog. That also did not work, so it may be that
there is some other issue involved. I am guessing that it might be related
to the saved start of memory location in the image header, but this is
just a guess.

Dave

Eliot Miranda-2

Re: A update to SystemTracer for getting back to 32 bits

Hi Dave, give me detailed instructions on what to load (or preferably an image ready to go) and I'll fix this.

Eliot (phone)

On Jan 12, 2015, at 10:20 AM, "David T. Lewis" <[hidden email]> wrote:

>> On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
>>>
>>> I made a minor update to the SystemTracer that allows it to convert a
>>> 64-bit
>>> image back to 32-bit format, and it worked perfectly with my working
>>> Squeak
>>> image that has been in 64-bit format for several months now.
>>
>> Nice!
>>
>>> The resulting 32-bit image must be opened first using an interpreter
>>> VM,
>>> after which it can be run normally with a Cog VM. Tracing should be
>>> done
>>> using an interpreter VM.
>>
>> Why is that?
>
> I have not yet figured out why it did not work with Cog. One possibility
> is that the system is running a jitted method at the time of the trace,
> and when the new 64-bit image wakes up in the interpreter VM, it is still
> in the middle of that method and the VM does not know what to do with it.
>
> That said, I also tried tracing 64 back to 32 and then running the traced
> 32-bit image immediately in Cog. That also did not work, so it may be that
> there is some other issue involved. I am guessing that it might be related
> to the saved start of memory location in the image header, but this is
> just a guess.
>
> Dave
>
>
>

David T. Lewis

Re: A update to SystemTracer for getting back to 32 bits

Hi Eliot,

You can use any 6504/6505 image. Just load the tracer from
http://www.squeaksource.com/SystemTracing or from SqueakMap.

To trace an existing 32-bit (format 6504 or 6505) image to 64-bit format:

SystemTracer64 writeImage: 'clone64.image'

To trace an 64-bit (format 68002) image to 32-bit format:

SystemTracer2 writeImage: 'clone32.image'

For a VM to run the 68002 image, you can use
http://www.squeakvm.org/unix/release/Squeak-4.10.2.2614_64bit-linux_x86_64.tar.gz
(although it would be better to compile a new one, because I've fixed a
couple things since then).

I did not think to try it earlier, but you might get the same symptoms if
you trace a 32-bit image into 32-bit format. I'm away and can't check it
now, but that might be an easier way to figure out what is going on.

Dave

> Hi Dave, give me detailed instructions on what to load (or preferably an
> image ready to go) and I'll fix this.
>
> Eliot (phone)
>
> On Jan 12, 2015, at 10:20 AM, "David T. Lewis" <[hidden email]>
> wrote:
>
>>> On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
>>>>
>>>> I made a minor update to the SystemTracer that allows it to convert a
>>>> 64-bit
>>>> image back to 32-bit format, and it worked perfectly with my working
>>>> Squeak
>>>> image that has been in 64-bit format for several months now.
>>>
>>> Nice!
>>>
>>>> The resulting 32-bit image must be opened first using an interpreter
>>>> VM,
>>>> after which it can be run normally with a Cog VM. Tracing should be
>>>> done
>>>> using an interpreter VM.
>>>
>>> Why is that?
>>
>> I have not yet figured out why it did not work with Cog. One possibility
>> is that the system is running a jitted method at the time of the trace,
>> and when the new 64-bit image wakes up in the interpreter VM, it is
>> still
>> in the middle of that method and the VM does not know what to do with
>> it.
>>
>> That said, I also tried tracing 64 back to 32 and then running the
>> traced
>> 32-bit image immediately in Cog. That also did not work, so it may be
>> that
>> there is some other issue involved. I am guessing that it might be
>> related
>> to the saved start of memory location in the image header, but this is
>> just a guess.
>>
>> Dave
>>
>>
>>
>

David T. Lewis

Re: A update to SystemTracer for getting back to 32 bits

In reply to this post by David T. Lewis

On Mon, Jan 12, 2015 at 01:20:27PM -0500, David T. Lewis wrote:

> > On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
> >>
> >> I made a minor update to the SystemTracer that allows it to convert a 64-bit
> >> image back to 32-bit format, and it worked perfectly with my working Squeak
> >> image that has been in 64-bit format for several months now.
> >
> > Nice!
> >
> >> The resulting 32-bit image must be opened first using an interpreter VM,
> >> after which it can be run normally with a Cog VM. Tracing should be done
> >> using an interpreter VM.
> >
> > Why is that?
> >
>
> I have not yet figured out why it did not work with Cog. One possibility
> is that the system is running a jitted method at the time of the trace,
> and when the new 64-bit image wakes up in the interpreter VM, it is still
> in the middle of that method and the VM does not know what to do with it.
>
> That said, I also tried tracing 64 back to 32 and then running the traced
> 32-bit image immediately in Cog. That also did not work, so it may be that
> there is some other issue involved. I am guessing that it might be related
> to the saved start of memory location in the image header, but this is
> just a guess.

Well D'oh!

I was driving home this afternoon and it popped into my head. I am quite
sure the the problem is due to the change in floating point word ordering
in the Cog image format (6505). If you trace an image that is running under
a Cog VM on a little endian host, the Float objects will require special
handling to put them back into the original canonical format (which is not
the native machine order on a little endian machine).

That is the reason that it does not work.

Dave

Bert Freudenberg

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
>
> I was driving home this afternoon and it popped into my head. I am quite
> sure the the problem is due to the change in floating point word ordering
> in the Cog image format (6505). If you trace an image that is running under
> a Cog VM on a little endian host, the Float objects will require special
> handling to put them back into the original canonical format (which is not
> the native machine order on a little endian machine).

But the word accessors in Float handle that I thought? Or don't they, in 64 bits?

- Bert -

smime.p7s (5K) Download Attachment

David T. Lewis

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

> On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
>>
>> I was driving home this afternoon and it popped into my head. I am quite
>> sure the the problem is due to the change in floating point word
>> ordering
>> in the Cog image format (6505). If you trace an image that is running
>> under
>> a Cog VM on a little endian host, the Float objects will require special
>> handling to put them back into the original canonical format (which is
>> not
>> the native machine order on a little endian machine).
>
> But the word accessors in Float handle that I thought? Or don't they, in
> 64 bits?
>
> - Bert -
>

This issue would be that the in-memory representation of the float objects
(which contain two 4-byte words of data) have the words reversed (i.e. put
into machine word order) when running on Cog on a little endian machine.
That in-memory representation is the thing being written out to disk
during the trace. The tracer thinks that it is writing objects with fields
in the original (format 6504, non-Cog) format, and it does not know when
it encounters a Float object that it needs to swap the data words. The
reason that it does not know this is that nobody has implemented it yet
:-)

Dave

Bert Freudenberg

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

> On 13.01.2015, at 17:30, David T. Lewis <[hidden email]> wrote:
>
>> On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
>>>
>>> I was driving home this afternoon and it popped into my head. I am quite
>>> sure the the problem is due to the change in floating point word
>>> ordering
>>> in the Cog image format (6505). If you trace an image that is running
>>> under
>>> a Cog VM on a little endian host, the Float objects will require special
>>> handling to put them back into the original canonical format (which is
>>> not
>>> the native machine order on a little endian machine).
>>
>> But the word accessors in Float handle that I thought? Or don't they, in
>> 64 bits?
>>
>> - Bert -
>>
>
> This issue would be that the in-memory representation of the float objects
> (which contain two 4-byte words of data) have the words reversed (i.e. put
> into machine word order) when running on Cog on a little endian machine.
> That in-memory representation is the thing being written out to disk
> during the trace. The tracer thinks that it is writing objects with fields
> in the original (format 6504, non-Cog) format, and it does not know when
> it encounters a Float object that it needs to swap the data words. The
> reason that it does not know this is that nobody has implemented it yet
> :-)
>
> Dave

I know that. I also know that Float>>basicAt: uses primitive 38 which is designed to always answer the words of a Float as if they were stored in big-endian order, no matter what the actual memory order is.

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

On Tue, Jan 13, 2015 at 8:59 AM, Bert Freudenberg <[hidden email]> wrote:

> On 13.01.2015, at 17:30, David T. Lewis <[hidden email]> wrote:
>
>> On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
>>>
>>> I was driving home this afternoon and it popped into my head. I am quite
>>> sure the the problem is due to the change in floating point word
>>> ordering
>>> in the Cog image format (6505). If you trace an image that is running
>>> under
>>> a Cog VM on a little endian host, the Float objects will require special
>>> handling to put them back into the original canonical format (which is
>>> not
>>> the native machine order on a little endian machine).
>>
>> But the word accessors in Float handle that I thought? Or don't they, in
>> 64 bits?
>>
>> - Bert -
>>
>
> This issue would be that the in-memory representation of the float objects
> (which contain two 4-byte words of data) have the words reversed (i.e. put
> into machine word order) when running on Cog on a little endian machine.
> That in-memory representation is the thing being written out to disk
> during the trace. The tracer thinks that it is writing objects with fields
> in the original (format 6504, non-Cog) format, and it does not know when
> it encounters a Float object that it needs to swap the data words. The
> reason that it does not know this is that nobody has implemented it yet
> :-)
>
> Dave

I know that. I also know that Float>>basicAt: uses primitive 38 which is designed to always answer the words of a Float as if they were stored in big-endian order, no matter what the actual memory order is.

And Float>>basicAt:put: uses primitive 39. I had to add these to Cog so that the VM was free for the underlying platform to choose the most efficient representation. It is a shame that we're saddled with a bug-endian order since large integers are little endian. But don't sweat the petty stuff, pet the sweaty stuff...

best,

Eliot

David T. Lewis

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

In reply to this post by Bert Freudenberg

>
>> On 13.01.2015, at 17:30, David T. Lewis <[hidden email]> wrote:
>>
>>> On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
>>>>
>>>> I was driving home this afternoon and it popped into my head. I am
>>>> quite
>>>> sure the the problem is due to the change in floating point word
>>>> ordering
>>>> in the Cog image format (6505). If you trace an image that is running
>>>> under
>>>> a Cog VM on a little endian host, the Float objects will require
>>>> special
>>>> handling to put them back into the original canonical format (which is
>>>> not
>>>> the native machine order on a little endian machine).
>>>
>>> But the word accessors in Float handle that I thought? Or don't they,
>>> in
>>> 64 bits?
>>>
>>> - Bert -
>>>
>>
>> This issue would be that the in-memory representation of the float objects
>> (which contain two 4-byte words of data) have the words reversed (i.e. put
>> into machine word order) when running on Cog on a little endian machine.
>> That in-memory representation is the thing being written out to disk
>> during the trace. The tracer thinks that it is writing objects with
>> fields
>> in the original (format 6504, non-Cog) format, and it does not know when
>> it encounters a Float object that it needs to swap the data words. The
>> reason that it does not know this is that nobody has implemented it yet
>> :-)
>>
>> Dave
>
> I know that. I also know that Float>>basicAt: uses primitive 38 which is
> designed to always answer the words of a Float as if they were stored in
> big-endian order, no matter what the actual memory order is.
>

I think the primitive handles processor word ordering, but does not know
about the float word ordering convention in Cog. In the interpreter VM, we
check the "cog bit" in the image format number at image load time, and
undo the float word ordering if the bit is set and if we are on a little
endian machine.

Come to think of it, I'll bet that just setting the cog bit in the traced
image header would be sufficient to address this. The 64-bit image would
be waking up in an interpreter VM, so it should hopefully notice the cog
bit and do the necessary Float word reordering. I'll have to give that a
try when I get home.

Dave

David T. Lewis

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

On Tue, Jan 13, 2015 at 04:05:05PM -0500, David T. Lewis wrote:

> >
> >> On 13.01.2015, at 17:30, David T. Lewis <[hidden email]> wrote:
> >>
> >>> On 13.01.2015, at 03:29, David T. Lewis <[hidden email]> wrote:
> >>>>
> >>>> I was driving home this afternoon and it popped into my head. I am quite
> >>>> sure the the problem is due to the change in floating point word ordering
> >>>> in the Cog image format (6505). If you trace an image that is running under
> >>>> a Cog VM on a little endian host, the Float objects will require special
> >>>> handling to put them back into the original canonical format (which is not
> >>>> the native machine order on a little endian machine).
> >>>
> >>> But the word accessors in Float handle that I thought? Or don't they, in
> >>> 64 bits?
> >>>
> >>> - Bert -
> >>
> >> This issue would be that the in-memory representation of the float objects
> >> (which contain two 4-byte words of data) have the words reversed (i.e. put
> >> into machine word order) when running on Cog on a little endian machine.
> >> That in-memory representation is the thing being written out to disk
> >> during the trace. The tracer thinks that it is writing objects with
> >> fields
> >> in the original (format 6504, non-Cog) format, and it does not know when
> >> it encounters a Float object that it needs to swap the data words. The
> >> reason that it does not know this is that nobody has implemented it yet
> >> :-)
> >>
> >> Dave
> >
> > I know that. I also know that Float>>basicAt: uses primitive 38 which is
> > designed to always answer the words of a Float as if they were stored in
> > big-endian order, no matter what the actual memory order is.
> >
>
> I think the primitive handles processor word ordering, but does not know
> about the float word ordering convention in Cog. In the interpreter VM, we
> check the "cog bit" in the image format number at image load time, and
> undo the float word ordering if the bit is set and if we are on a little
> endian machine.
>
> Come to think of it, I'll bet that just setting the cog bit in the traced
> image header would be sufficient to address this. The 64-bit image would
> be waking up in an interpreter VM, so it should hopefully notice the cog
> bit and do the necessary Float word reordering. I'll have to give that a
> try when I get home.

Confirmed.

If I trace a 32-bit image that is running on Cog and set the image format
number of the traced 64-bit image to 68003 rather than 68002, then the
resulting 64-bit image can be opened by a squeak64 interpreter VM. And BTW
the image trace runs much faster using Cog.

Tracing that 64-bit image back to 32-bits still requires that the traced
32-bit image be opened first with an interpreter VM, after which it can
be saved and run from a Cog VM. I do not know the reason for this, but
I expect that it is a different issue than the Float word ordering issue
discussed here.

Dave

David T. Lewis

Re: A update to SystemTracer for getting back to 32 bits

In reply to this post by Bert Freudenberg

On Mon, Jan 12, 2015 at 04:52:32PM +0100, Bert Freudenberg wrote:

> On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
> >
> > I made a minor update to the SystemTracer that allows it to convert a 64-bit
> > image back to 32-bit format, and it worked perfectly with my working Squeak
> > image that has been in 64-bit format for several months now.
>
> Nice!
>
> > The resulting 32-bit image must be opened first using an interpreter VM,
> > after which it can be run normally with a Cog VM. Tracing should be done
> > using an interpreter VM.
>
> Why is that?
>
> - Bert -
>

The issue was Float word ordering differences in Cog/StackInterpreter. I made
an update to SystemTracer that mostly handles this, the main benefit being
that Cog can now be used to execute a much faster system trace from 32-bit
image to 64-bit 68002 (or the mythical 68003) image, non-Spur:

Name: SystemTracing-dtl.27
Time: 15 January 2015, 10:20:22.019 pm

Allow 32-bit images to be traced to 64-bit using 32-bit Cog VM. Handle float
word ordering differences between StackInterpreter and Interpreter. Produces
a runnable 68003 image, 64-bit object format, closures, and Cog float word
ordering. Requires package ImageFormat from VMMaker repository, else error
is raised indicating how to hard code a workaround. This seems a reasonable
dependency given the increasing number of image formats in circulation.

Trace from 64-bit image to 32-bit still requires an initial load and save
using an interpreter VM prior to running with Cog, reason unknown.

Dave

Eliot Miranda-2

Re: [Vm-dev] Re: [squeak-dev] A update to SystemTracer for getting back to 32 bits

Hi David,

On Thu, Jan 15, 2015 at 7:43 PM, David T. Lewis <[hidden email]> wrote:

On Mon, Jan 12, 2015 at 04:52:32PM +0100, Bert Freudenberg wrote:
> On 12.01.2015, at 01:47, David T. Lewis <[hidden email]> wrote:
> >
> > I made a minor update to the SystemTracer that allows it to convert a 64-bit
> > image back to 32-bit format, and it worked perfectly with my working Squeak
> > image that has been in 64-bit format for several months now.
>
> Nice!
>
> > The resulting 32-bit image must be opened first using an interpreter VM,
> > after which it can be run normally with a Cog VM. Tracing should be done
> > using an interpreter VM.
>
> Why is that?
>
> - Bert -
>

The issue was Float word ordering differences in Cog/StackInterpreter. I made
an update to SystemTracer that mostly handles this, the main benefit being
that Cog can now be used to execute a much faster system trace from 32-bit
image to 64-bit 68002 (or the mythical 68003) image, non-Spur:

Name: SystemTracing-dtl.27
Time: 15 January 2015, 10:20:22.019 pm

Allow 32-bit images to be traced to 64-bit using 32-bit Cog VM. Handle float
word ordering differences between StackInterpreter and Interpreter. Produces
a runnable 68003 image, 64-bit object format, closures, and Cog float word
ordering. Requires package ImageFormat from VMMaker repository, else error
is raised indicating how to hard code a workaround. This seems a reasonable
dependency given the increasing number of image formats in circulation.

Trace from 64-bit image to 32-bit still requires an initial load and save
using an interpreter VM prior to running with Cog, reason unknown.

Dave

Great!

best,

Eliot