Apologies - this was a cut and paste error on my part, and does not belong in trunk, please ignore. The Collections-ar.269 should supercede it in the update stream, so it should not cause problems.
(FYI, I am trying to reconstruct some of historical SystemTracer implementations in order to put them into Monticello on SqueakSource, with the latest versions being able to trace current images to 64 bit format thanks to recent work by John McIntosh.)
Dave
On Thu, Dec 31, 2009 at 11:01:21PM +0000, commits@source.squeak.org wrote:
David T. Lewis uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-dtl.268.mcz
==================== Summary ====================
Name: Collections-dtl.268 Author: dtl Time: 31 December 2009, 5:57:13 am UUID: 70cf7086-91e9-4d1f-a078-eaf82e6208fb Ancestors: Collections-ul.267
Add remaining portions of NewSystemTracer-ajh, with classes and methods recategoried to SystemTracing.
=============== Diff against Collections-ul.267 ===============
Item was changed: Stream subclass: #PositionableStream instanceVariableNames: 'collection position readLimit'
- classVariableNames: 'IntBuffer'
classVariableNames: '' poolDictionaries: '' category: 'Collections-Streams'!
!PositionableStream commentStamp: '<historical>' prior: 0! I represent an accessor for a sequence of objects (a collection) that are externally named by indices so that the point of access can be repositioned. I am abstract in that I do not implement the messages next and nextPut: which are inherited from my superclass Stream.!
On 12/31/09 9:11 PM, "David T. Lewis" lewis@mail.msen.com wrote:
(FYI, I am trying to reconstruct some of historical SystemTracer implementations in order to put them into Monticello on SqueakSource, with the latest versions being able to trace current images to 64 bit format thanks to recent work by John McIntosh.)
Dave
Dave:
I have interest in 64 bit images, as John knows. In particular in opening Dan old 64 bit image and in PPC VM running in Tiger (John don't do it AFAIK) Any to share ?
Edgar
On Fri, Jan 01, 2010 at 07:01:33AM -0200, Edgar J. De Cleene wrote:
On 12/31/09 9:11 PM, "David T. Lewis" lewis@mail.msen.com wrote:
(FYI, I am trying to reconstruct some of historical SystemTracer implementations in order to put them into Monticello on SqueakSource, with the latest versions being able to trace current images to 64 bit format thanks to recent work by John McIntosh.)
Dave
Dave:
I have interest in 64 bit images, as John knows. In particular in opening Dan old 64 bit image and in PPC VM running in Tiger (John don't do it AFAIK) Any to share ?
Hi Edgar,
You can run a 64-bit image on any machine, including 32-bit Intel. The "64-bit" in the image is just the size of the words in the object memory.
The original 64-bit image that Dan and Ian created is this: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
but unfortunately this image can no longer be run on current Squeak VMs. The reason is that some changes were made to the VM that broke backward compatibility.
There is another version of the same image here: http://squeakvm.org/squeak64/sq64-dtl.zip
This is the original image from Dan and Ian with some updates that I did over the years. So anyone who wants to try running a 64-bit image can do this: 1) Build a VM for 64-bit images by selecting the "64-bit image" checkbox on the VMMaker tool. 2) Use this VM to run the image http://squeakvm.org/squeak64/sq64-dtl.zip
The Squeak trunk image has not yet been converted to 64-bit image format, but I believe that this probably can be done now. John McIntosh has updated the SystemTracer to work properly with modern images, and he and others report that they have successfully traced new Pharo images into 64-bit mode. The notes for this are scattered around several mailing lists, but I think that what needs to be done is this:
1) Fix a word size bug in CompiledMethod>>initialPC. I'll add the fix to trunk some time soon, but am waiting for now to make sure we don't implement differently from Pharo. Status of this issue is on Mantis http://bugs.squeak.org/view.php?id=7430
2) Load the new SystemTracer with John's fixes. I'll try to get this into a SqueakSource archive along with the earlier SystemTracer versions so that everyone can access it more easily. In the mean time, you can google for System-Tracing.2forPharo.cs to find John's latest update.
3) Trace the Squeak trunk image into 64-bit format.
The last step must be done with a big-endian machine (Intel will not work), so maybe you will be able to help with that step in the process :)
Dave
On 1/1/10 2:43 PM, "David T. Lewis" lewis@mail.msen.com wrote:
The original 64-bit image that Dan and Ian created is this: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
but unfortunately this image can no longer be run on current Squeak VMs. The reason is that some changes were made to the VM that broke backward compatibility.
There is another version of the same image here: http://squeakvm.org/squeak64/sq64-dtl.zip
Sure it's the same ?
Squeak64-3.8g-6548.image. I could run this image with a Unix powerpc-apple-darwin7.8.0 and not with John , suppose is the http://squeakvm.org, but noty sure.
sq64-dtl. image. Not run
My trouble is my old G4 QuickSilver only runs Tiger (10.4), not Leopard (10.5) or Snow Leopard (10.6).
For the rest, I try to follow your advice, many thanks.
For the record, I put again the bike photos in http://190.193.83.211/~admin/MotosAntiguas/
I remember you like it....
Be patient, cable modem is sloooow
Edgar
Morning.
So in order to use a 64bit image on a 32bit machine running a 32bit VM you need to build a VM that is for 32bit machines but is configured to use 64bit image.
In order to build that with the isqueak.org VM tree you have to change the SQ_VI_BYTES_PER_WORD to 8
#define SQ_VI_BYTES_PER_WORD 8
Then compile for 32bit powerpc using the SqueakPureObjc64*64. Normally that is configured for 64 bit intel only, so you'll have to fiddle a bit.
I've done that and put it as
experimental/64bit/64bitImage*32bitVMPowerPC/Squeak 32/64 5.1b1 PowerPC.app.zip
in the regular places via http://smalltalkconsulting.com/squeak.html
I note there is a fair amount of warning: implicit conversion shortens 64-bit value into a 32-bit value technically those should be cross checked and changed to cast the sqInt aka (long long) to the target (long/NSInteger) The issue here is that a sqInt value which is a long long and typically a 32bit integer value is being assigned to a NSInteger (long). Other places are where a long long is passed as a void* pointer, so it's being converted from 64bit to a 32bits void *
But I'll leave those fixes & cross checks as an exercise for the user...
The VM doesn't have any plugins. I think the only plugin that you could compile is for FreeType. Existing plugins will not work because they are being passed long long values from squeak where they are expecting a long value.
On 2010-01-01, at 10:32 AM, Edgar J. De Cleene wrote:
On 1/1/10 2:43 PM, "David T. Lewis" lewis@mail.msen.com wrote:
The original 64-bit image that Dan and Ian created is this: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
but unfortunately this image can no longer be run on current Squeak VMs. The reason is that some changes were made to the VM that broke backward compatibility.
There is another version of the same image here: http://squeakvm.org/squeak64/sq64-dtl.zip
Sure it's the same ?
Squeak64-3.8g-6548.image. I could run this image with a Unix powerpc-apple-darwin7.8.0 and not with John , suppose is the http://squeakvm.org, but noty sure.
sq64-dtl. image. Not run
My trouble is my old G4 QuickSilver only runs Tiger (10.4), not Leopard (10.5) or Snow Leopard (10.6).
For the rest, I try to follow your advice, many thanks.
For the record, I put again the bike photos in http://190.193.83.211/~admin/MotosAntiguas/
I remember you like it....
Be patient, cable modem is sloooow
Edgar
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
Dave
On Fri, Jan 01, 2010 at 01:08:24PM -0800, John M McIntosh wrote:
Morning.
So in order to use a 64bit image on a 32bit machine running a 32bit VM you need to build a VM that is for 32bit machines but is configured to use 64bit image.
In order to build that with the isqueak.org VM tree you have to change the SQ_VI_BYTES_PER_WORD to 8
#define SQ_VI_BYTES_PER_WORD 8
Then compile for 32bit powerpc using the SqueakPureObjc64*64. Normally that is configured for 64 bit intel only, so you'll have to fiddle a bit.
I've done that and put it as
experimental/64bit/64bitImage*32bitVMPowerPC/Squeak 32/64 5.1b1 PowerPC.app.zip
in the regular places via http://smalltalkconsulting.com/squeak.html
I note there is a fair amount of warning: implicit conversion shortens 64-bit value into a 32-bit value technically those should be cross checked and changed to cast the sqInt aka (long long) to the target (long/NSInteger) The issue here is that a sqInt value which is a long long and typically a 32bit integer value is being assigned to a NSInteger (long). Other places are where a long long is passed as a void* pointer, so it's being converted from 64bit to a 32bits void *
But I'll leave those fixes & cross checks as an exercise for the user...
The VM doesn't have any plugins. I think the only plugin that you could compile is for FreeType. Existing plugins will not work because they are being passed long long values from squeak where they are expecting a long value.
On 2010-01-01, at 10:32 AM, Edgar J. De Cleene wrote:
On 1/1/10 2:43 PM, "David T. Lewis" lewis@mail.msen.com wrote:
The original 64-bit image that Dan and Ian created is this: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
but unfortunately this image can no longer be run on current Squeak VMs. The reason is that some changes were made to the VM that broke backward compatibility.
There is another version of the same image here: http://squeakvm.org/squeak64/sq64-dtl.zip
Sure it's the same ?
Squeak64-3.8g-6548.image. I could run this image with a Unix powerpc-apple-darwin7.8.0 and not with John , suppose is the http://squeakvm.org, but noty sure.
sq64-dtl. image. Not run
My trouble is my old G4 QuickSilver only runs Tiger (10.4), not Leopard (10.5) or Snow Leopard (10.6).
For the rest, I try to follow your advice, many thanks.
For the record, I put again the bike photos in http://190.193.83.211/~admin/MotosAntiguas/
I remember you like it....
Be patient, cable modem is sloooow
Edgar
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Hi,
I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version.
For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is:
--- initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 ---
The fix will be integrated in Pharo soon. It is also in attachment.
Cheers
On Jan 3, 2010, at 06:46 , John M McIntosh wrote:
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
--- Jannik Laval ---
Jannik
did you check the changeset in the mantis bug report?
Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote:
Hi,
I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version.
For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is:
initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1
The fix will be integrated in Pharo soon. It is also in attachment.
<addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs>
Cheers
On Jan 3, 2010, at 06:46 , John M McIntosh wrote:
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Jannik Laval
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, but the changeset build the fix in SystemDictionary, In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too.
Cheers, Jannik
On Jan 4, 2010, at 13:35 , Stéphane Ducasse wrote:
Jannik
did you check the changeset in the mantis bug report?
Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote:
Hi,
I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version.
For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is:
initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1
The fix will be integrated in Pharo soon. It is also in attachment.
<addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs>
Cheers
On Jan 3, 2010, at 06:46 , John M McIntosh wrote:
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Jannik Laval
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
excellent
On Jan 4, 2010, at 1:44 PM, Laval Jannik wrote:
Yes, but the changeset build the fix in SystemDictionary, In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too.
Cheers, Jannik
On Jan 4, 2010, at 13:35 , Stéphane Ducasse wrote:
Jannik
did you check the changeset in the mantis bug report?
Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote:
Hi,
I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version.
For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is:
initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1
The fix will be integrated in Pharo soon. It is also in attachment.
<addWordSizeInSystemDictionary.1.cs><System-Tracing-forPharo.cs>
Cheers
On Jan 3, 2010, at 06:46 , John M McIntosh wrote:
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Jannik Laval
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Laval Jannik wrote:
I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version.
For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup.
This may be the stupid question of the day, but can someone explain to me why we aren't just hard-wiring the word size (say in a CompiledMethod class var or so)? It's not like the primitive would *ever* return anything else unless you grind the image through SystemTracer, and if you do that, SystemTracer can simply update those values. It seems silly to build caches, primitives, cache invalidation for a value which will never ever change dynamically. Besides I think the cache invalidation might be wrong - how do you know that initialPC or other word size related methods aren't sent before the startUp method is executed?
Cheers, - Andreas
The method initialPC is:
initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1
The fix will be integrated in Pharo soon. It is also in attachment.
Cheers
On Jan 3, 2010, at 06:46 , John M McIntosh wrote:
Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image
On 2010-01-02, at 6:46 PM, David T. Lewis wrote:
John, one additional note.
The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionary>>wordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original "dist3" 64-bit image does not work on current VMs.
You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40.
This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Jannik Laval
Hi Andreas,
This may be the stupid question of the day, but can someone explain to me why we aren't just hard-wiring the word size (say in a CompiledMethod class var or so)? It's not like the primitive would *ever* return anything else unless you grind the image through SystemTracer,
the value of wordSize is initialized only one time, If wordSize is nil, it takes the value of the primitive 40.
and if you do that, SystemTracer can simply update those values.
Yes, it does. SystemTracer pushes the value of primitive 40 in wordSize.
It seems silly to build caches, primitives, cache invalidation for a value which will never ever change dynamically. Besides I think the cache invalidation might be wrong -
The "cache" is synchronized with the VM only one time after the creation of the image, I think it is better than a hard-writing value.
how do you know that initialPC or other word size related methods aren't sent before the startUp method is executed?
startUp method is the first method executed at the startup, no ?
But in SystemTracer, the value is initialized in "clonePreStartup" method. So there is no problem with potential method calls before startUp.
Cheers,
- Andreas
Cheers,
--- Jannik Laval ---
Hi Jannik -
A couple of comments. First, If wordSize is a constant, put it into a class var. That's the best practice pattern for dealing with constants and I see no reason why one would opt to use an ivar for a value that never changes. See for example the EndianCache in SmalltalkImage and other use of constants throughout the system.
As for caching, if I understand your description correctly, then system tracer is storing the correct value for the traced image. When the image starts, your cache code invalidates the known to be correct value which is later lazily filled in with the same value again. So what observable effect does your cache invalidation have?
#startUp isn't the first method sent, not by a very long shot - in particular when you mess with the execution machinery you have to be aware that a method like #initialPC might be called before you ever get to the point where you invalidate that cache (I'm not sure if this can happen in this concrete case). In any case you should trace through the startup sequence to find out just how much other code is executed before getting there.
My recommendations would be to make WordSize a class variable, leave the lazy initialization in (it might be helpful during install etc) but add a nice comment explaining that only system tracer ever modifies that value when a 32/64 bit image is written. And leave out the pointless cache invalidation :-)
Cheers, - Andreas
Laval Jannik wrote:
Hi Andreas,
This may be the stupid question of the day, but can someone explain to me why we aren't just hard-wiring the word size (say in a CompiledMethod class var or so)? It's not like the primitive would *ever* return anything else unless you grind the image through SystemTracer,
the value of wordSize is initialized only one time, If wordSize is nil, it takes the value of the primitive 40.
and if you do that, SystemTracer can simply update those values.
Yes, it does. SystemTracer pushes the value of primitive 40 in wordSize.
It seems silly to build caches, primitives, cache invalidation for a value which will never ever change dynamically. Besides I think the cache invalidation might be wrong -
The "cache" is synchronized with the VM only one time after the creation of the image, I think it is better than a hard-writing value.
how do you know that initialPC or other word size related methods aren't sent before the startUp method is executed?
startUp method is the first method executed at the startup, no ?
But in SystemTracer, the value is initialized in "clonePreStartup" method. So there is no problem with potential method calls before startUp.
Cheers,
- Andreas
Cheers,
Jannik Laval
On Mon, Jan 04, 2010 at 05:15:28PM +0100, Andreas Raab wrote:
Hi Jannik -
A couple of comments. First, If wordSize is a constant, put it into a class var. That's the best practice pattern for dealing with constants and I see no reason why one would opt to use an ivar for a value that never changes. See for example the EndianCache in SmalltalkImage and other use of constants throughout the system.
As for caching, if I understand your description correctly, then system tracer is storing the correct value for the traced image. When the image starts, your cache code invalidates the known to be correct value which is later lazily filled in with the same value again. So what observable effect does your cache invalidation have?
#startUp isn't the first method sent, not by a very long shot - in particular when you mess with the execution machinery you have to be aware that a method like #initialPC might be called before you ever get to the point where you invalidate that cache (I'm not sure if this can happen in this concrete case). In any case you should trace through the startup sequence to find out just how much other code is executed before getting there.
John and/or Bert previously pointed out that there is no need to ever set the cached value from the image, so this would be done from a system tracer only (and yes this should have a comment).
My recommendations would be to make WordSize a class variable, leave the lazy initialization in (it might be helpful during install etc) but add a nice comment explaining that only system tracer ever modifies that value when a 32/64 bit image is written. And leave out the pointless cache invalidation :-)
I think that the change set on Mantis 7430 does what you describe. This puts the class variable in SystemDictionary in order to retain the current "Smalltalk wordSize" idiom, and uses the original Dan Ingalls #initialPC implementation from the "dist3" 64-bit image.
It's a small change, so I'll copy it here:
'From Squeak3.10.2 of 16 December 2009 [latest update: #8496] on 18 December 2009 at 6:08:11 pm'! "Change Set: Smalltalk-wordSize-dtl-M7430 Date: 18 December 2009 Author: David T. Lewis
Cache Smalltalk wordSize in class var in SystemDictionary..
Update CompiledMethod>>initialPC to use #wordSize. This is the method as implemented in the original 64-bit image (author di)."!
IdentityDictionary subclass: #SystemDictionary instanceVariableNames: 'cachedClassNames' classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' poolDictionaries: '' category: 'System-Support'!
!CompiledMethod methodsFor: 'accessing' stamp: 'di 6/29/2004 12:28'! initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * Smalltalk wordSize + 1 ! !
!SystemDictionary methodsFor: 'sources, change log' stamp: 'dtl 12/18/2009 00:32'! wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize"
^ WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]! !
David T. Lewis wrote:
I think that the change set on Mantis 7430 does what you describe. This puts the class variable in SystemDictionary in order to retain the current "Smalltalk wordSize" idiom, and uses the original Dan Ingalls #initialPC implementation from the "dist3" 64-bit image.
It's a small change, so I'll copy it here:
Yes, that's nice and simple. Ship it :-)
Cheers, - Andreas
why its not using SmalltalkImage current vmParameterAt: 40 all the time?
Why keeping this excessive information in ivar/classvar and inventing workarounds how to update it carefully because of SystemTracer mangling?
just my 2 cents.
On Mon, Jan 04, 2010 at 06:49:53PM +0200, Igor Stasenko wrote:
why its not using SmalltalkImage current vmParameterAt: 40 all the time?
Why keeping this excessive information in ivar/classvar and inventing workarounds how to update it carefully because of SystemTracer mangling?
Normally that would be the right thing to do, but in the case of #initialPC the performance impact of the primitive call has a significant impact. Eliot was quite keen to make sure we did not add that overhead in the #initialPC call, hence the class variable to save the value.
Dave
Hi,
I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer
Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ?
Cheers, Jannik
On Jan 4, 2010, at 17:39 , David T. Lewis wrote:
On Mon, Jan 04, 2010 at 05:15:28PM +0100, Andreas Raab wrote:
Hi Jannik -
A couple of comments. First, If wordSize is a constant, put it into a class var. That's the best practice pattern for dealing with constants and I see no reason why one would opt to use an ivar for a value that never changes. See for example the EndianCache in SmalltalkImage and other use of constants throughout the system.
As for caching, if I understand your description correctly, then system tracer is storing the correct value for the traced image. When the image starts, your cache code invalidates the known to be correct value which is later lazily filled in with the same value again. So what observable effect does your cache invalidation have?
#startUp isn't the first method sent, not by a very long shot - in particular when you mess with the execution machinery you have to be aware that a method like #initialPC might be called before you ever get to the point where you invalidate that cache (I'm not sure if this can happen in this concrete case). In any case you should trace through the startup sequence to find out just how much other code is executed before getting there.
John and/or Bert previously pointed out that there is no need to ever set the cached value from the image, so this would be done from a system tracer only (and yes this should have a comment).
My recommendations would be to make WordSize a class variable, leave the lazy initialization in (it might be helpful during install etc) but add a nice comment explaining that only system tracer ever modifies that value when a 32/64 bit image is written. And leave out the pointless cache invalidation :-)
I think that the change set on Mantis 7430 does what you describe. This puts the class variable in SystemDictionary in order to retain the current "Smalltalk wordSize" idiom, and uses the original Dan Ingalls #initialPC implementation from the "dist3" 64-bit image.
It's a small change, so I'll copy it here:
'From Squeak3.10.2 of 16 December 2009 [latest update: #8496] on 18 December 2009 at 6:08:11 pm'! "Change Set: Smalltalk-wordSize-dtl-M7430 Date: 18 December 2009 Author: David T. Lewis
Cache Smalltalk wordSize in class var in SystemDictionary..
Update CompiledMethod>>initialPC to use #wordSize. This is the method as implemented in the original 64-bit image (author di)."!
IdentityDictionary subclass: #SystemDictionary instanceVariableNames: 'cachedClassNames' classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' poolDictionaries: '' category: 'System-Support'!
!CompiledMethod methodsFor: 'accessing' stamp: 'di 6/29/2004 12:28'! initialPC "Answer the program counter for the receiver's first bytecode."
^ (self numLiterals + 1) * Smalltalk wordSize + 1 ! !
!SystemDictionary methodsFor: 'sources, change log' stamp: 'dtl 12/18/2009 00:32'! wordSize "Answer the size (in bytes) of an object pointer." "Smalltalk wordSize"
^ WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]! !
On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote:
Hi,
I understand your comments, So:
- i will put word size a class var,
- this class var will be modify only by systemTracer
Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ?
Hi Jannik,
Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary ("Smalltalk") rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years.
As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say "Smalltalk wordSize" to refer to the size of a word in the object memory, or whether "SmalltalkImage current wordSize" is more meaningful.
FWIW, my own opinion is that neither one is right, but "Smalltalk wordSize" is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-)
HTH,
Dave
Thank you Dave,
Jannik
On Jan 4, 2010, at 21:16 , David T. Lewis wrote:
On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote:
Hi,
I understand your comments, So:
- i will put word size a class var,
- this class var will be modify only by systemTracer
Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ?
Hi Jannik,
Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary ("Smalltalk") rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years.
As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say "Smalltalk wordSize" to refer to the size of a word in the object memory, or whether "SmalltalkImage current wordSize" is more meaningful.
FWIW, my own opinion is that neither one is right, but "Smalltalk wordSize" is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-)
HTH,
Dave
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Fri, Jan 01, 2010 at 04:32:38PM -0200, Edgar J. De Cleene wrote:
On 1/1/10 2:43 PM, "David T. Lewis" lewis@mail.msen.com wrote:
The original 64-bit image that Dan and Ian created is this: http://squeakvm.org/squeak64/dist3/Squeak64-3.8g-6548.image.tar.gz
but unfortunately this image can no longer be run on current Squeak VMs. The reason is that some changes were made to the VM that broke backward compatibility.
There is another version of the same image here: http://squeakvm.org/squeak64/sq64-dtl.zip
Sure it's the same ?
Squeak64-3.8g-6548.image. I could run this image with a Unix powerpc-apple-darwin7.8.0 and not with John , suppose is the http://squeakvm.org, but noty sure.
sq64-dtl. image. Not run
My trouble is my old G4 QuickSilver only runs Tiger (10.4), not Leopard (10.5) or Snow Leopard (10.6).
Probably you will need to compile the VM yourself then. I do not know much about building software on a Mac, but John provides lots of documentation in the platforms/Mac OS/vm/Documentation directory.
To make the VM for 64-bit images, there is a checkbox on the VMMakerTool for "64-bit image". If you do not use VMMaker, maybe it is enough to just edit the file src/vm/interp.h and change SQ_VI_BYTES_PER_WORD from 4 to 8.
For the rest, I try to follow your advice, many thanks.
For the record, I put again the bike photos in http://190.193.83.211/~admin/MotosAntiguas/
I remember you like it....
Be patient, cable modem is sloooow
Great photos, thanks!
Dave
On 2010-01-02, at 12:22 PM, David T. Lewis wrote:
Probably you will need to compile the VM yourself then. I do not know much about building software on a Mac, but John provides lots of documentation in the platforms/Mac OS/vm/Documentation directory.
To make the VM for 64-bit images, there is a checkbox on the VMMakerTool for "64-bit image". If you do not use VMMaker, maybe it is enough to just edit the file src/vm/interp.h and change SQ_VI_BYTES_PER_WORD from 4 to 8.
For the isqueak.org SVN tree it contains the xCode folder and a premade VMMaker source folder for 32 and 64 bits, so it's a matter of picking the target and checking the setting of the SQ_VI_BYTES_PER_WORD I've not included any instructions about how VMMaker works or what the settings are, because you should just be able to SVN sync and do "build and go" within xCode.
At the moment you can build a 32 bit vm, 32bit image for macIntel 32 bit, powerpc 32bit. 64 bit vm, 32bit image for macIntel 64 bit.
Technically the above three binaries are built and folded into the same binary with the 32bit host/64bit vm target
The other VM flavour I have built is 32 bit vm, 64bit image for macIntel 32bit, powerpc 32bit However I only released the 32 bit vm, 64bit image for powerpc 32bit for testing. I've also not checked any of the 64 bit to 32bit implicit truncation messages for this variant.
The same xCode project builds the VM for the iPhone since it shares much of the base code with the OSX version. The only variant is 32 bit vm, 32bit image arm 6 & 7
It should be possible to build a 32 bit vm, 64bit image arm 6 & 7
But I've not seen a need for that, obviously a 64bit image is 2x larger and memory on the iPhone is precious so why would you want to do that?
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Edgar J. De Cleene -
Igor Stasenko -
John M McIntosh -
Laval Jannik -
Stéphane Ducasse