Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
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
david I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair. Now we can either have a namespace class (with only namespace behavior) and a imageManagement class Now we could have one variable Smalltalk to point to either of it. but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth. Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name => namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information so if you have ideas please let me know. Stef On Jan 4, 2010, at 9:16 PM, 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
david
I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair.
Now we can either have a namespace class (with only namespace behavior) both and a imageManagement class
Now we could have one variable Smalltalk to point to either of it. them :) but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth.
Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name => namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information
so if you have ideas please let me know.
Stef
On Jan 4, 2010, at 9:16 PM, 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Jan 04, 2010 at 09:30:45PM +0100, St?phane Ducasse wrote:
david
I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair.
Now we can either have a namespace class (with only namespace behavior) and a imageManagement class
Now we could have one variable Smalltalk to point to either of it. but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth.
Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name => namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information
so if you have ideas please let me know.
Stef, I think it would be good to step away from the details and just think about the high level objects - what do they represent and what are they responsible for (http://www.wirfs-brock.com/Design.html)? Maybe there would be two or three classes involved, as few as possible. Then write the class comments for the empty classes. Think about it for a few weeks, and if it still makes sense then start the refactoring. But I would not touch a single line of code until the class comments are clearly written and understood. $0.02, Dave
On Jan 4, 2010, at 10:47 PM, David T. Lewis wrote:
On Mon, Jan 04, 2010 at 09:30:45PM +0100, St?phane Ducasse wrote:
david
I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair.
Now we can either have a namespace class (with only namespace behavior) and a imageManagement class
Now we could have one variable Smalltalk to point to either of it. but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth.
Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name => namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information
so if you have ideas please let me know.
Stef,
I think it would be good to step away from the details and just think about the high level objects - what do they represent and what are they responsible for (http://www.wirfs-brock.com/Design.html)?
this is couple of years that I'm teaching oop design :) And I have been thinking about how to solve the social and historical issue around smalltalk since years.
Maybe there would be two or three classes involved, as few as possible. Then write the class comments for the empty classes. Think about it for a few weeks, and if it still makes sense then start the refactoring. But I would not touch a single line of code until the class comments are clearly written and understood.
We already did that. This is the easy part. The problem is the overload of Smalltalk (the global name). Now SmalltalkImage could be called SmalltalkImageManagamentClass :) and its singleton be a global name smalltalkImage and it could be reached via Smalltalk Thinking about it we could avoid a global and have messages (much better) Smalltalk -> points to Namespace instance = SystemDictionary singleton Smalltalk image -> points to SmalltalkImage current Smalltalk vm -> points to SmalltalkImage/VM current Now it means that we get only one real global Which is good if one day we want to have real namespace or can help people like gulik to have them in. Of course this promote Smalltalk image snaphot kind of style Stef
participants (3)
-
David T. Lewis -
Laval Jannik -
Stéphane Ducasse