The Trunk: Collections-dtl.268.mcz
Locked
12
12
 
|
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.! |
Re: The Trunk: Collections-dtl.268.mcz
|
|
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, [hidden email] 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.! > |
64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
On 12/31/09 9:11 PM, "David T. Lewis" <[hidden email]> 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 |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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" <[hidden email]> 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 |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
On 1/1/10 2:43 PM, "David T. Lewis" <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
In reply to this post by Edgar J. De Cleene
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" <[hidden email]> 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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
In reply to this post by johnmci
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 <[hidden email]> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > Jannik Laval ---  addWordSizeInSystemDictionary.1.cs (3K) Download Attachment System-Tracing-forPharo.cs (61K) Download Attachment |
Re: [Pharo-project] 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> > > --- > Jannik Laval > --- > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-project] 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 <[hidden email]> Twitter: squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >>> >>> >> >> --- >> Jannik Laval >> --- >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [Pharo-project] 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 <[hidden email]> Twitter: squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> =========================================================================== >>>> >>>> >>>> >>>> >>> >>> --- >>> Jannik Laval >>> --- >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
In reply to this post by jannik laval
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 <[hidden email]> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> > > --- > Jannik Laval > --- > > > > ------------------------------------------------------------------------ > > |
Re: Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 --- |
Re: Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 > --- |
Re: Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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]]! ! |
Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
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 |
Re: Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
|
|
In reply to this post by David T. Lewis
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. -- Best regards, Igor Stasenko AKA sig. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |