hi david

the systemTracing package for pharo is available in PharoTaskForces I do not know what changed compared with the one of squeak.

Stef

On Dec 8, 2011, at 6:49 PM, David T. Lewis wrote:

This is an update to the system tracer that makes it possible to trace current Squeak images to 64-bit image format. Prior to this update, only pre-closure images could be converted to 64-bit object format.

Thanks to Eliot for the tip that pointed me to the solution, which is that instances of BlockClosure need to have the value of their startpc instance variable adjusted to match byte offsets in the enclosing compiled method when converting from 32-bit to 64-bit object format.

This works on Squeak, not yet tested on Pharo.

Dave

On Thu, Dec 08, 2011 at 05:17:49AM +0000, squeak-dev-noreply@lists.squeakfoundation.org wrote:

...

Dave Lewis uploaded a new version of SystemTracing to project SystemTracing: http://www.squeaksource.com/SystemTracing/SystemTracing-dtl.23.mcz

==================== Summary ====================

Name: SystemTracing-dtl.23 Author: dtl Time: 7 December 2011, 11:17:47 am UUID: 9f6136af-8117-416c-bf54-baf2a32bb571 Ancestors: SystemTracing-dtl.22

Support tracing closure-enabled images to 64-bit object format.

When tracing to a different word size, e.g. trace to 64-bit image from a 32-bit image, adjust the startpc of all BlockClosure instances to account for different word size in the enclosing compiled method.

Hi Stef,

I loaded the PharoTaskForces version of SystemTracing into a Pharo image, then did the update to handle block closures. I was able to convert the Pharo 1.4 image to 64-bit format and run it under an interpreter VM for 64-bit object memory.

To update the PharoTaskForces version, you can file in the attached SystemTracer2-writeAndTrace.st. This will not cause any problems for tracing to 32-bit formats, but will allow you to also trace to a 64-bit format if you like.

You also will want to fix SystemTracer64>>writeFileHeader to use 'Smalltalk vm extraVMMemory' instead of 'SmalltalkImage current extraVMMemory' otherwise you will get a deprecation warning that will hang your image after doing the trace.

Dave

On Fri, Dec 09, 2011 at 05:30:16PM -0500, David T. Lewis wrote:

Thanks Stef,

I'll try to look at it when I get a chance. I did a quick check with Pharo 1.4, but I just did not have enough time to follow up on the issues. I'll have a look at PharoTaskForces because I'm sure it's addressed there.

Dave

On Fri, Dec 09, 2011 at 10:52:44PM +0100, stephane ducasse wrote:

...

hi david

the systemTracing package for pharo is available in PharoTaskForces I do not know what changed compared with the one of squeak.

Stef

On Dec 8, 2011, at 6:49 PM, David T. Lewis wrote:

...

This is an update to the system tracer that makes it possible to trace current Squeak images to 64-bit image format. Prior to this update, only pre-closure images could be converted to 64-bit object format.

Thanks to Eliot for the tip that pointed me to the solution, which is that instances of BlockClosure need to have the value of their startpc instance variable adjusted to match byte offsets in the enclosing compiled method when converting from 32-bit to 64-bit object format.

This works on Squeak, not yet tested on Pharo.

Dave

On Thu, Dec 08, 2011 at 05:17:49AM +0000, squeak-dev-noreply@lists.squeakfoundation.org wrote:

...

Dave Lewis uploaded a new version of SystemTracing to project SystemTracing: http://www.squeaksource.com/SystemTracing/SystemTracing-dtl.23.mcz

==================== Summary ====================

Name: SystemTracing-dtl.23 Author: dtl Time: 7 December 2011, 11:17:47 am UUID: 9f6136af-8117-416c-bf54-baf2a32bb571 Ancestors: SystemTracing-dtl.22

Support tracing closure-enabled images to 64-bit object format.

When tracing to a different word size, e.g. trace to 64-bit image from a 32-bit image, adjust the startpc of all BlockClosure instances to account for different word size in the enclosing compiled method.

Thanks I committed it. Now I have a question

SystemTracer64 is to run on 64

How do I say to SystemTracer or SystemTracer2 that I want to convert or not to 64 bits? Because I thought (stupidly) that SystemTracer2 was for 32->32

Stef

excllent I will add that in the class comments.

Stef

On Dec 12, 2011, at 12:43 PM, David T. Lewis wrote:

On Mon, Dec 12, 2011 at 08:18:41AM +0100, stephane ducasse wrote:

...

Thanks I committed it.

Thanks, next time I will do it myself :)

...

Now I have a question

SystemTracer64 is to run on 64

How do I say to SystemTracer or SystemTracer2 that I want to convert or not to 64 bits? Because I thought (stupidly) that SystemTracer2 was for 32->32

No, you are correct. SystemTracer2 is for 32->32. SystemTracer is the original version, which IMO is useful for education to understand how these things work, but is not useful with current images.

SystemTracer64 is for converting an existing (32-bit format) image to the experimental 64-bit object format. It is a subclass of SystemTracer2 with methods for converting headers, oops, and fields from the normal 32-bit format to the 64-bit format.

This is sometimes confusing, because people may assume that a 64-bit image is for 64-bit platforms, but actually it is only about the internal data formats. You can run a 32-bit image on a 64-bit platform, so for example there is no reason that you could not run a 64-bit image on a 32-bit Cog VM (this would require some development in the oscog VMMaker but no reason it cannot be done). I say this because people may assume that 32-bit Cog could not be used for 64-bit images, but this is not really true.

If you invent a new object format (as I expect that Eliot will do), then you might create a new subclass of SystemTracer2 that would know how to convert to that format.

Dave

luc did you check what pavel mentioned in the pharo mailing-list. Because may be the UI thread should be kick in again.

I do not know.

Stef On Dec 26, 2011, at 11:30 PM, Luc Fabresse wrote:

Hi Guys,

I am certainly doing something wrong while using SystemTracer. I tried SystemTracing-StephaneDucasse.25 (on ss in PharoTaskForces) both in a Pharo 1.3 and 1.4. I did: SystemTracer2 writeImage: 'test.image' tracing and writing work well but the when I launch the resulting test.image, UI is not responsive. It seems that it is just a UI problem.

Any hint?

Thanks,

#Luc

2011/12/12 stephane ducasse stephane.ducasse@gmail.com

excllent I will add that in the class comments.

Stef

On Dec 12, 2011, at 12:43 PM, David T. Lewis wrote:

...

On Mon, Dec 12, 2011 at 08:18:41AM +0100, stephane ducasse wrote:

...

Thanks I committed it.

Thanks, next time I will do it myself :)

...

Now I have a question

SystemTracer64 is to run on 64

How do I say to SystemTracer or SystemTracer2 that I want to convert or not to 64 bits? Because I thought (stupidly) that SystemTracer2 was for 32->32

No, you are correct. SystemTracer2 is for 32->32. SystemTracer is the original version, which IMO is useful for education to understand how these things work, but is not useful with current images.

SystemTracer64 is for converting an existing (32-bit format) image to the experimental 64-bit object format. It is a subclass of SystemTracer2 with methods for converting headers, oops, and fields from the normal 32-bit format to the 64-bit format.

This is sometimes confusing, because people may assume that a 64-bit image is for 64-bit platforms, but actually it is only about the internal data formats. You can run a 32-bit image on a 64-bit platform, so for example there is no reason that you could not run a 64-bit image on a 32-bit Cog VM (this would require some development in the oscog VMMaker but no reason it cannot be done). I say this because people may assume that 32-bit Cog could not be used for 64-bit images, but this is not really true.

If you invent a new object format (as I expect that Eliot will do), then you might create a new subclass of SystemTracer2 that would know how to convert to that format.

Dave