2011/4/26 Mariano Martinez Peck <[email protected]> > > > On Tue, Apr 26, 2011 at 6:59 PM, Eliot Miranda <[email protected]>wrote: > >> Mariano, >> >> the point is that it is classes that manage adding methods to classes >> and hence it is their private behavior to flush the VM's method cache. >> > > Ok...I agree, but still it is misleading when we are talking about "method > cache". Because methods are in classes...so I promise everybody that didn't > know and you ask what Behavior >> flushCache does, and everybody will say > that it flushed the cache of the methods of that class, not the whole cache. > I can understand CompiledMethod >> flushCache and even Symbol >> flushCache > ... but this one looks really strange. > > >> You'll see "self flushCache" in Smalltalk-80 v2 images. >> > > that makes more sense indeed > > >> Now of course the VM provides selective cache flushing but back in the >> day adding or removing a method implied flushing the whole cache. >> Personally I don't see that this justifies adding Smalltalk vm yet. I >> would wait until you have a few more use cases. >> > > Sorry but in this case, I disagree. I think the opposite: it is the perfect > moment to reify the VM in the image and start using it. Why? exactly > because right now we have few uses and it is really easy to migrate. In > fact, for Behavior >> flushCache there are only 3 senders. And I don't > pretend to remove them right now, but with the normal deprecation policy. > This is, in Pharo 1.3 we let the messages like Behavior >> flushCache, > SmalltalkImage >> vmVersion, etc. But we let them as deprecated explaining > that now they should use XXX. And of course, inside the image we do fix the > senders. > > In fact, in Pharo 1.3, the method SmalltalkImage >> vm > "Answer the object to query about virtual machine." > > ^self > > already exists :) > > I see the following possible behavior for VM right now (I mean, the > following methods are already in SmalltalkImage): > > - #flushCache > - #buildDate > - #interpreterSourceVersion > - #platformSourceVersion > - #versionLabel > - #extraVMMemory > - #extraVMMemory: > - #gcBiasToGrow: > - #gcBiasToGrowLimit: > - #getVMParameters > - #primitiveGCBiasToGrow: > - #vmParameterAt: > -#vmParameterAt:put: > - #reportCPUandRAM > - #vmStatisticsReportString > - #vmStatisticsShortString > > So....I think they are enough. And the sooner we do this, the easier it > would be to reify the VM in the image. >
Yes I agree Mariano. And I also suggest to put meaningful selectors for vmparameters because I can't remember the indexes. e.g: VirtualMachine>>maximumNumberOfSemaphores ^ self vmParameterAt: 49 Luc > > Cheers > > Mariano > > > >> >> On Tue, Apr 26, 2011 at 3:34 AM, Mariano Martinez Peck < >> [email protected]> wrote: >> >>> Hi. As far as I can see, >>> >>> Behavior >> flushCache >>> "Tell the interpreter to remove the contents of its method lookup >>> cache, if it has >>> one. Essential. See Object documentation whatIsAPrimitive." >>> >>> <primitive: 89> >>> self primitiveFailed >>> >>> >>> And primitive 89 does nothing in particular with the receiver (the class >>> in this case). In both, InterpreterVM and Cog, the WHOLE cache is flushed, >>> there is NOTHING related to the receiver class. Of course, that's at least >>> what it looks for me (please tell me if I am wrong). >>> So...if this is the case, wouldn't make sense to move it elsewhere? like >>> Smalltalk flushCache or Smalltalk vm flushCache (and it is a good moment to >>> reify the VM). So after we can do: Smalltalk vm version. Smalltlak vm >>> flushCache, Smalltalk vm parameterAt: , etc.... >>> >>> If you don't like doing "Smalltalk vm" then we can create a VM class with >>> all class methods, or a singleton and use #current or a singleton and put it >>> in Smalltalk globals...etc >>> >>> We will need to fix a couple of senders, thus. >>> >>> What do you think? For me is really confusing, and you don't understand >>> it until you see the primitive implementation. >>> >>> Cheers >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >
