Vm-dev September 2011

vm-dev@lists.squeakfoundation.org

35 participants
70 discussions

VM Maker: VMMaker.oscog-eem.127.mcz
by commits＠source.squeak.org 23 Sep '11

23 Sep '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.127.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.127 Author: eem Time: 23 September 2011, 1:44:07.265 pm UUID: 35927684-7e1e-4ff8-ad9f-90ecec7bb9a0 Ancestors: VMMaker.oscog-eem.126 Fix MNU PIC creation not to answer an error code to the interpreter. This is the demon call 0x00000013 bug. =============== Diff against VMMaker.oscog-eem.126 =============== Item was changed: ----- Method: Cogit>>cogMNUPICSelector:methodOperand:numArgs: (in category 'in-line cacheing') ----- cogMNUPICSelector: selector methodOperand: methodOperand numArgs: numArgs <api> "Attempt to create a one-case PIC for an MNU. The tag for the case is at the send site and so doesn't need to be generated." <returnTypeC: #'CogMethod *'> | startAddress headerSize size end | coInterpreter compilationBreak: selector point: (objectMemory lengthOf: selector). + self assert: endCPICCase0 notNil. - endCPICCase0 isNil ifTrue: - [^self cCoerceSimple: NotFullyInitialized to: #'CogMethod *']. startAddress := methodZone allocate: closedPICSize. startAddress = 0 ifTrue: + [coInterpreter callForCogCompiledCodeCompaction. + ^0]. - [^self cCoerceSimple: InsufficientCodeSpace to: #'CogMethod *']. methodLabel address: startAddress; dependent: nil. "stack allocate the various collections so that they are effectively garbage collected on return." self allocateOpcodes: numPICCases * 7 bytecodes: 0. self compileMNUCPIC: (self cCoerceSimple: startAddress to: #'CogMethod *') methodOperand: methodOperand numArgs: numArgs. self computeMaximumSizes. headerSize := self sizeof: CogMethod. size := self generateInstructionsAt: startAddress + headerSize. end := self outputInstructionsAt: startAddress + headerSize. "The missOffset is the same as the interpretOffset." self assert: missOffset = (interpretCall address + interpretCall machineCodeSize - startAddress). self assert: startAddress + cmEntryOffset = entry address. ^self fillInCPICHeader: (self cCoerceSimple: startAddress to: #'CogMethod *') size: closedPICSize numArgs: numArgs numCases: 1 hasMNUCase: true selector: selector !

1 0

new Cog VMs available [please read]
by Eliot Miranda 23 Sep '11

23 Sep '11

...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/. These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing. These 2493 VMs contain code to help identify that bug. If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap. I want to see C stack backtraces from these VMs whenever they crash. Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window). The C backtrace part of things looks like this on windows: Stack backtrace: [004193EA] ??? + 4297706 in CogCode [00442337] ??? + 4465463 in CogCode [00442685] ??? + 4466309 in CogCode [00583018] ??? + 5779480 in CogCode [0040124B] ??? + 4198987 in CogCode [00401298] ??? + 4199064 in CogCode [7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll [7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll this on Mac C stack backtrace: 0 nsvm 0x00038689 reportStackState + 105 1 nsvm 0x0003893e sigsegv + 110 2 libsystem_c.dylib 0x9b2e259b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 nsvm 0x0008b2a5 sufficientSpaceAfterGC + 69 5 nsvm 0x0008d11d primitiveNewWithArg + 221 6 ??? 0x068b9899 0x0 + 109811865 7 nsvm 0x00098d10 initStackPagesAndInterpret + 512 8 nsvm 0x0002c530 EventLoopEventHandler + 16 Etc. So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs. Hopefully I'll track down this regression quickly. For the curious, what's the bug? I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit. These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug. Here's the 2493 readme: CogVM binaries as per VMMaker.oscog-eem.125/r2493. Add callsite link/relocate checks to catch the call 0x00000013 MNU callsite relinking bug. Reduce the size of the simStack to something proportional to LargeContextSize. In the Newspeak VM, don't cd to the image's directory on win32. Fix off-by-one error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't include an erroneous trailing null. Fix the 1Gb allocation bug. -- best, Eliot

2 3

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM
by Eliot Miranda 23 Sep '11

23 Sep '11

On Thu, Sep 22, 2011 at 11:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Igor, > > On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: > >> On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > (apologies for the duplicate reply; someone needs to sort out their >> > threading for the benefit of the community ;) ) >> > >> > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> >> > wrote: >> >> >> >> Hi, >> >> >> >> There are two changesets waiting for integrating in 1.4 that have >> serious >> >> consequences: >> >> >> >> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, >> >> but have not >> >> been integrated in the VMMaker codebase. >> >> >> >> http://code.google.com/p/pharo/issues/detail?id=4265 >> > >> > I would *really* like to back out these changes. The Ephemeron >> > implementation is very much a prototype, requiring a hack to determine >> > whether an object is an ephemeron (the presence of a marker class in >> the >> > first inst var) that I'm not at all happy with. There is a neater >> > implementation available via using an unused instSpec which IMO has >> > significant advantages (much simpler & faster, instSpec is valid at all >> > times, including during compaction, less overhead, doesn't require a >> marker >> > class), and is the route I'm taking with the new >> GC/object-representation >> > I'm working on now. Note that other than determining whether an object >> is >> > an ephemeron (instSpec/format vs inst var test) the rest of Igor's code >> > remains the same. I'd like to avoid too much VM forking. Would you all >> > consider putting these changes on hold for now? >> > If so, I'll make the effort to produce prototype changes (in the area of >> > ClassBuilder and class definition; no VM code necessary as yet) to allow >> > defining Ephemerons via the int spec route by next week at the latest. >> > >> >> i agree that in my implementation this is a weak point. But its hard >> to do anything without >> making changes to object format to identify these special objects. >> >> The main story behind this is can we afford to change the internals of >> VM without being beaten hard >> by "backwards compatibility" party? :) >> > > I don't think we get stuck in this at all. The instSpec/format field has > an unused value (5 i believe) and this can easily be used for Ephemerons. > All that is needed is a little image work on these methods: > > Behavior>>typeOfClass > needs to answer e.g. #ephemeron for ephemeron classes > > ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: > needs to accept e.g. #ephemeron for type and pass variable: false > and weak: true for ephemerons to format:variable:words:pointers:weak:. > > ClassBuilder>>format:variable:words:pointers:weak: > needs to respond to variable: false and weak: true by computing the > ephemeron instSpec. > > > Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > need siblings, e.g. > > ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category > > superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > Right? This is easy. Then in the VM there are a few places where pointer > indexability (formats 3 and 4) need to be firmed up to exclude 5, but > nothing difficult. We talked about this in email last week. > Here's the format field (Behavior>instSpec at the image level) as currently populated: 0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 6 = 32-bit indexable objects (Float, Bitmap ert al) 8 = 8-bit indexable objects (ByteString, ByteArray et al) 12 = CompiledMethod N.B. in the VM the least two bits of the format/instSpec for byte objects (formats 8 and 12) is used to encode the number of odd bytes in the object, so that a 1 character ByteString has a format of 11, = 8 + 3, size = 1 word - 3 bytes. For the future (i.e. the new GC/object representation, /not/ for the first implementation of ephemerons which we can do now, for Pharo 1.4 or 1.5) we need to extend format/instSpec to support 64 bits. I think format needs to be made a 5 bit field with room for 4 bits of odd bytes for 64-bit images. [For VMers, the Size4Bit is a horrible hack). So then 0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron) and we need 8 CompiledMethod values, 8 byte values, 4 16-bit values, 2 32-bit values and a 64-bit value, = 23 values, 23 + 5 = 30, so there is room, e.g. 9 (?) 64-bit indexable 10 - 11 32-bit indexable 12 - 15 16-bit indexable 16 - 23 byte indexable 24 - 31 compiled method In 32-bit images only the least significant 2 bits would be used for formats 16 & 24, and the least significant bit for format 12. > >> >> Ephemerons are versatile way to get notifications of objects which are >> about to die, >> and there are certain parts in language which is hard (or even >> impossible) to implement without ephemerons. >> >> I got stuck with it earlier, when realized that we cannot afford to >> have weak subscriptions in announcement framework >> for blocks (which is most convenient and most easy way to define >> subscriptions) without having ephemerons. >> And of course, by having ephemerons we can completely review the weak >> finalization scheme and make it >> much simpler, and faster. >> >> I think we should do something in this regard, even at cost of >> backward compatibility. >> Because as to me it blocks us from moving forward. >> >> I wanted to remind to people, that it took me around a day to >> implement ephemerons in VM. And then few more days >> to actually make a correct implementation and write tests to cover it. >> >> Unfortunately, we yet don't have a well established process, which >> could make VM + language side changes to go in sync, >> when its required, and go much faster and don't fear to >> introduce/change functionality. >> One of the reasons for having a continuous integration setup for VM >> was exactly for that: >> having new VMs every day (comparing to having new VMs every year). >> >> >> >> >> - Finalization code checks for #hasNewFinalization >> >> This is true in the current VMs build in Jenkins, but in older VMs >> this >> >> is not in. >> >> >> >> http://code.google.com/p/pharo/issues/detail?id=4483 >> >> >> >> There are two options: >> >> >> >> a) integrate in >> >> b) not integrate it >> >> >> >> a) means that the image runs on older VMs, too. >> >> b) means we accept that we can never improve anything for real. >> >> >> >> There will be more changes coming... e.g. imagine we have a Vector >> >> Graphics Canvas >> >> as some point next year... what will we do? use it or not use it to >> stay >> >> compatible? >> >> >> >> Marcus >> >> >> >> >> >> -- >> >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > -- best, Eliot

4 7

Re: [Vm-beginners] Got "Error: basicNew: failed" when running InterpreterSimulator
by Mariano Martinez Peck 23 Sep '11

23 Sep '11

On Fri, Sep 23, 2011 at 6:40 AM, Nick. <nick.lsts(a)gmail.com> wrote: > Hi guys! > > In the past few days i tried to get InterpreterSimulator running without > success. > First of all, a little context about my goal: I'm digging into the VM > because i would like to be able to delegate to some class (that I'll > develop) the responsibility for, say, the method lookup algorithm. > > With that in mind, here's what i've been doing: > Using the Pharo 1.2 image Mariano Peck's prepared in his exellent article > (http://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/), > loaded > the VMMaker package with the following script: > > Deprecation raiseWarning: false. > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfCog'; > load. > (Smalltalk at: #ConfigurationOfCog) project latestVersion load. > > Once it finishes (without errors) I "Save As" the current image as > "demo.image", close it and open the original Pharo 1.2 image that Mariano > provided. > When, for example, I run: > > (CogVMSimulator new openOn: 'demo.image') test > or > (InterpreterSimulatorLSB new openOn: 'demo.image') test > > I get the following error: "Error: basicNew: failed" (see attached images > at > the end). > Weird. Something I remember about the simulator is that you need to run it with a VM that has the BochsIA32Plugin. Try Eliot's VM that will have it for sure. But anywya, I doesn't look related to your particula problem. > When I tried to load VMMaker in the Pharo 1.3 OneClick release, I got > another error (see attached images at the end). > > Yes, because you need some changes in order to make it work. I have attached those changes in the post. But those changes should be already integrated in latests Pharo 1.3. You don't have that error in the image I put of 1.2 because that image comes already with such changes. > Am I doing something wrong? > Are those the right simulators to use? I can tell the difference between > all > that are available in VMMaker package. > > Well...it depends on what you want. FOr example, if you build a stack VM then you should use instead StackInterpreterSimulator. So..for the Cog VM I guess it is CogVMSimulator. If you go to here: http://www.squeakvm.org/svn/squeak/branches/Cog/image/ you can see http://www.squeakvm.org/svn/squeak/branches/Cog/image/VM%20Simulation%20Wor… It might be outdated, but it can be a start point. cheers > Thanks in advance! > > Nick > > > > http://forum.world.st/file/n3835723/error_while_trying_to_run_InterpreterSi… > > http://forum.world.st/file/n3835723/Error_while_loading_VMMaker_in_Pharo-1.… > > > > -- > View this message in context: > http://forum.world.st/Got-Error-basicNew-failed-when-running-InterpreterSim… > Sent from the Smalltalk VM - Beginners mailing list archive at Nabble.com. > _______________________________________________ > VM-beginners mailing list > VM-beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners > -- Mariano http://marianopeck.wordpress.com

1 0

Re: [squeak-dev] new Cog VMs available [please read]
by Eliot Miranda 23 Sep '11

23 Sep '11

On Thu, Sep 22, 2011 at 12:58 PM, Tony Garnock-Jones <tonyg(a)ccs.neu.edu>wrote: > On 2011-09-22 1:37 PM, Eliot Miranda wrote: > > If you're already using a > > 2487 VM or newer > > How do I find the VM version? Pressing cmd-I on the .app in Finder gives > a version of "Croquet Cog 4.0.0 http://www.mirandabanda.org". Presumably > there's an in-image way of finding out? > (1007 to: 1009) collect: [:i| Smalltalk getSystemAttribute: i] which may have a nicer wrapper (e.g. included in About Squeak?). 1009 answers the svn revision and url in my VMs and the analogous info in Igor's VMs. > Regards, > Tony > -- best, Eliot

2 1

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM
by Eliot Miranda 23 Sep '11

23 Sep '11

On Thu, Sep 22, 2011 at 11:28 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 September 2011 20:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Igor, > > > > On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > (apologies for the duplicate reply; someone needs to sort out their > >> > threading for the benefit of the community ;) ) > >> > > >> > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker < > marcus.denker(a)inria.fr> > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> There are two changesets waiting for integrating in 1.4 that have > >> >> serious > >> >> consequences: > >> >> > >> >> - Ephemerons. The VM level changes are in the Cog VMs build on > Jenkins, > >> >> but have not > >> >> been integrated in the VMMaker codebase. > >> >> > >> >> http://code.google.com/p/pharo/issues/detail?id=4265 > >> > > >> > I would *really* like to back out these changes. The Ephemeron > >> > implementation is very much a prototype, requiring a hack to determine > >> > whether an object is an ephemeron (the presence of a marker class in > >> > the > >> > first inst var) that I'm not at all happy with. There is a neater > >> > implementation available via using an unused instSpec which IMO has > >> > significant advantages (much simpler & faster, instSpec is valid at > all > >> > times, including during compaction, less overhead, doesn't require a > >> > marker > >> > class), and is the route I'm taking with the new > >> > GC/object-representation > >> > I'm working on now. Note that other than determining whether an > object > >> > is > >> > an ephemeron (instSpec/format vs inst var test) the rest of Igor's > code > >> > remains the same. I'd like to avoid too much VM forking. Would you > all > >> > consider putting these changes on hold for now? > >> > If so, I'll make the effort to produce prototype changes (in the area > of > >> > ClassBuilder and class definition; no VM code necessary as yet) to > allow > >> > defining Ephemerons via the int spec route by next week at the latest. > >> > > >> > >> i agree that in my implementation this is a weak point. But its hard > >> to do anything without > >> making changes to object format to identify these special objects. > >> > >> The main story behind this is can we afford to change the internals of > >> VM without being beaten hard > >> by "backwards compatibility" party? :) > > > > I don't think we get stuck in this at all. The instSpec/format field has > an > > unused value (5 i believe) and this can easily be used for Ephemerons. > All > > that is needed is a little image work on these methods: > > Behavior>>typeOfClass > > needs to answer e.g. #ephemeron for ephemeron classes > > ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: > > needs to accept e.g. #ephemeron for type and pass variable: false > > and weak: true for ephemerons to format:variable:words:pointers:weak:. > > ClassBuilder>>format:variable:words:pointers:weak: > > needs to respond to variable: false and weak: true by computing > the > > ephemeron instSpec. > > > > > Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > > > > ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > need siblings, e.g. > > > > > ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category > > > > > superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > Right? This is easy. Then in the VM there are a few places where > pointer > > indexability (formats 3 and 4) need to be firmed up to exclude 5, but > > nothing difficult. We talked about this in email last week. > > > > Do you think this will require boosting an image format version number? > That would make sense. Boosting it so that the new VMs can run older images and newer, ephemeron images, but that ephemeron images won't open on older VMs. Yes, this makes perfect sense. > I think it is, because clearly, an images which expect ephemerons to > function cannot work with older VMs properly without > support of ephemerons. > > And will lead us to numerous reports "cannot open your f*king image" > with my VM :) > Internally, discussing with Marcus and Stef we came to agreement, that > for each Pharo release we should ship > own version of VM (signed appropriately), so then there will be less > confusion. We also thinking that VM versioning > in future should follow the image versioning, again to make things > simpler and to avoid confusion. > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

2 1

[commit] r2494 - CogVM source as per VMMaker.oscog-eem.126. Fix cPICEndSize mis-computation
by commits＠squeakvm.org 23 Sep '11

23 Sep '11

Author: eliot Date: 2011-09-22 18:24:09 -0700 (Thu, 22 Sep 2011) New Revision: 2494 Modified: branches/Cog/nscogsrc/vm/cogit.c branches/Cog/nscogsrc/vm/cogit.h branches/Cog/nscogsrc/vm/cogmethod.h branches/Cog/platforms/Cross/vm/sqSCCSVersion.h branches/Cog/scripts/uploadvms branches/Cog/src/vm/cogit.c branches/Cog/src/vm/cogit.h branches/Cog/src/vm/cogmethod.h Log: CogVM source as per VMMaker.oscog-eem.126. Fix cPICEndSize mis-computation caused by using rounded-up closedPICSize. Compute cPICEndSize and /then/ round-up closedPICSize. Modified: branches/Cog/nscogsrc/vm/cogit.c =================================================================== --- branches/Cog/nscogsrc/vm/cogit.c 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/nscogsrc/vm/cogit.c 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 from - StackToRegisterMappingCogit VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + StackToRegisterMappingCogit VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -8377,9 +8377,10 @@ compileClosedPICPrototype(); computeMaximumSizes(); headerSize = sizeof(CogMethod); - closedPICSize = roundUpLength(headerSize + (generateInstructionsAt(methodZoneBase + headerSize))); + closedPICSize = headerSize + (generateInstructionsAt(methodZoneBase + headerSize)); firstCPICCaseOffset = ((endCPICCase0->address)) - methodZoneBase; cPICCaseSize = ((endCPICCase1->address)) - ((endCPICCase0->address)); + cPICEndSize = closedPICSize - (((numPICCases - 1) * cPICCaseSize) + firstCPICCaseOffset); /* self cCode: '' inSmalltalk: @@ -8388,7 +8389,7 @@ self disassembleFrom: methodZoneBase + headerSize to: end - 1. self halt] */ - cPICEndSize = closedPICSize - (((numPICCases - 1) * cPICCaseSize) + firstCPICCaseOffset); + closedPICSize = roundUpLength(closedPICSize); } @@ -15474,10 +15475,10 @@ byteAtput(retpc - 3, (((usqInt) distance) >> 8) & 255); byteAtput(retpc - 4, distance & 255); if (0) { - assert((callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)) >= (minCallAddress())); + assert((((usqInt) (callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)))) >= (minCallAddress())); } else { - if (!((callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)) >= (minCallAddress()))) { + if (!((((usqInt) (callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)))) >= (minCallAddress()))) { error("relocating call to invalid address"); } } @@ -15899,7 +15900,7 @@ byteAtput(callSiteReturnAddress - 2, (((usqInt) callDistance) >> 16) & 255); byteAtput(callSiteReturnAddress - 3, (((usqInt) callDistance) >> 8) & 255); byteAtput(callSiteReturnAddress - 4, callDistance & 255); - assert((callTargetFromReturnAddress(self_in_rewriteCallAttarget, callSiteReturnAddress)) == callTargetAddress); + assert((((usqInt) (callTargetFromReturnAddress(self_in_rewriteCallAttarget, callSiteReturnAddress)))) == callTargetAddress); return 5; } @@ -15935,7 +15936,7 @@ byteAtput(callSiteReturnAddress - 7, (((usqInt) cacheTag) >> 16) & 255); byteAtput(callSiteReturnAddress - 8, (((usqInt) cacheTag) >> 8) & 255); byteAtput(callSiteReturnAddress - 9, cacheTag & 255); - assert((callTargetFromReturnAddress(self_in_rewriteInlineCacheAttagtarget, callSiteReturnAddress)) == callTargetAddress); + assert((((usqInt) (callTargetFromReturnAddress(self_in_rewriteInlineCacheAttagtarget, callSiteReturnAddress)))) == callTargetAddress); return 10; } Modified: branches/Cog/nscogsrc/vm/cogit.h =================================================================== --- branches/Cog/nscogsrc/vm/cogit.h 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/nscogsrc/vm/cogit.h 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ Modified: branches/Cog/nscogsrc/vm/cogmethod.h =================================================================== --- branches/Cog/nscogsrc/vm/cogmethod.h 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/nscogsrc/vm/cogmethod.h 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ typedef struct { Property changes on: branches/Cog/platforms/Cross/vm/sqSCCSVersion.h ___________________________________________________________________ Modified: checkindate - Wed Sep 21 16:09:47 PDT 2011 + Thu Sep 22 18:21:48 PDT 2011 Modified: branches/Cog/scripts/uploadvms =================================================================== --- branches/Cog/scripts/uploadvms 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/scripts/uploadvms 2011-09-23 01:24:09 UTC (rev 2494) @@ -25,7 +25,7 @@ -l) ARCHIVES="$ARCHIVES coglinux.tgz nsvmlinux.tgz";; -m) ARCHIVES="$ARCHIVES Cog.app.tgz Newspeak Virtual Machine.app.tgz";; -w) ARCHIVES="$ARCHIVES cogwin.tgz nsvmwin.tgz";; - -?|-h) echo usage: $0 [-l -m -w -cl -cm -cw -nl -nm -nw]; exit 0 + -?|-h) echo usage: $0 [-l -m -w -cl -cm -cw -ctl -ctm -ctw -nl -nm -nw]; exit 0 esac shift done Modified: branches/Cog/src/vm/cogit.c =================================================================== --- branches/Cog/src/vm/cogit.c 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/src/vm/cogit.c 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,9 +1,9 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 from - StackToRegisterMappingCogit VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + StackToRegisterMappingCogit VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ -static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 " __DATE__ ; +static char __buildInfo[] = "StackToRegisterMappingCogit VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 " __DATE__ ; char *__cogitBuildInfo = __buildInfo; @@ -8288,9 +8288,10 @@ compileClosedPICPrototype(); computeMaximumSizes(); headerSize = sizeof(CogMethod); - closedPICSize = roundUpLength(headerSize + (generateInstructionsAt(methodZoneBase + headerSize))); + closedPICSize = headerSize + (generateInstructionsAt(methodZoneBase + headerSize)); firstCPICCaseOffset = ((endCPICCase0->address)) - methodZoneBase; cPICCaseSize = ((endCPICCase1->address)) - ((endCPICCase0->address)); + cPICEndSize = closedPICSize - (((numPICCases - 1) * cPICCaseSize) + firstCPICCaseOffset); /* self cCode: '' inSmalltalk: @@ -8299,7 +8300,7 @@ self disassembleFrom: methodZoneBase + headerSize to: end - 1. self halt] */ - cPICEndSize = closedPICSize - (((numPICCases - 1) * cPICCaseSize) + firstCPICCaseOffset); + closedPICSize = roundUpLength(closedPICSize); } @@ -15083,10 +15084,10 @@ byteAtput(retpc - 3, (((usqInt) distance) >> 8) & 255); byteAtput(retpc - 4, distance & 255); if (0) { - assert((callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)) >= (minCallAddress())); + assert((((usqInt) (callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)))) >= (minCallAddress())); } else { - if (!((callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)) >= (minCallAddress()))) { + if (!((((usqInt) (callTargetFromReturnAddress(self_in_relocateCallBeforeReturnPCby, retpc)))) >= (minCallAddress()))) { error("relocating call to invalid address"); } } @@ -15420,7 +15421,7 @@ byteAtput(callSiteReturnAddress - 2, (((usqInt) callDistance) >> 16) & 255); byteAtput(callSiteReturnAddress - 3, (((usqInt) callDistance) >> 8) & 255); byteAtput(callSiteReturnAddress - 4, callDistance & 255); - assert((callTargetFromReturnAddress(self_in_rewriteCallAttarget, callSiteReturnAddress)) == callTargetAddress); + assert((((usqInt) (callTargetFromReturnAddress(self_in_rewriteCallAttarget, callSiteReturnAddress)))) == callTargetAddress); return 5; } @@ -15456,7 +15457,7 @@ byteAtput(callSiteReturnAddress - 7, (((usqInt) cacheTag) >> 16) & 255); byteAtput(callSiteReturnAddress - 8, (((usqInt) cacheTag) >> 8) & 255); byteAtput(callSiteReturnAddress - 9, cacheTag & 255); - assert((callTargetFromReturnAddress(self_in_rewriteInlineCacheAttagtarget, callSiteReturnAddress)) == callTargetAddress); + assert((((usqInt) (callTargetFromReturnAddress(self_in_rewriteInlineCacheAttagtarget, callSiteReturnAddress)))) == callTargetAddress); return 10; } Modified: branches/Cog/src/vm/cogit.h =================================================================== --- branches/Cog/src/vm/cogit.h 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/src/vm/cogit.h 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ Modified: branches/Cog/src/vm/cogmethod.h =================================================================== --- branches/Cog/src/vm/cogmethod.h 2011-09-21 23:10:54 UTC (rev 2493) +++ branches/Cog/src/vm/cogmethod.h 2011-09-23 01:24:09 UTC (rev 2494) @@ -1,5 +1,5 @@ /* Automatically generated by - CCodeGenerator VMMaker.oscog-eem.125 uuid: 539c10db-ab19-4fc7-ada1-4ffae6463ed1 + CCodeGenerator VMMaker.oscog-eem.126 uuid: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 */ typedef struct {

1 0

VM Maker: VMMaker.oscog-eem.126.mcz
by commits＠source.squeak.org 23 Sep '11

23 Sep '11

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.126.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.126 Author: eem Time: 22 September 2011, 6:02:25.985 pm UUID: 6af3249f-6c5c-4e1b-8a69-f59e542154c5 Ancestors: VMMaker.oscog-eem.125 Cogit: Fix cPICEndSize mis-computation caused by using rounded-up closedPICSize. Compute cPICEndSize and /then/ round-up closedPICSize. Fix for simulation callTargetFromReturnAddress: asserts in relocation calls. =============== Diff against VMMaker.oscog-eem.125 =============== Item was changed: ----- Method: CogIA32Compiler>>relocateCallBeforeReturnPC:by: (in category 'inline cacheing') ----- relocateCallBeforeReturnPC: retpc by: delta | distance | delta ~= 0 ifTrue: [distance := ((objectMemory byteAt: retpc - 1) << 24) + ((objectMemory byteAt: retpc - 2) << 16) + ((objectMemory byteAt: retpc - 3) << 8) + (objectMemory byteAt: retpc - 4). distance := distance + delta. objectMemory byteAt: retpc - 1 put: (distance >> 24 bitAnd: 16rFF); byteAt: retpc - 2 put: (distance >> 16 bitAnd: 16rFF); byteAt: retpc - 3 put: (distance >> 8 bitAnd: 16rFF); byteAt: retpc - 4 put: (distance bitAnd: 16rFF). false + ifTrue: [self assert: (self callTargetFromReturnAddress: retpc) signedIntToLong >= cogit minCallAddress] + ifFalse: [(self callTargetFromReturnAddress: retpc) signedIntToLong >= cogit minCallAddress ifFalse: - ifTrue: [self assert: (self callTargetFromReturnAddress: retpc) >= cogit minCallAddress] - ifFalse: [(self callTargetFromReturnAddress: retpc) >= cogit minCallAddress ifFalse: [self error: 'relocating call to invalid address']]]! Item was changed: ----- Method: CogIA32Compiler>>rewriteCallAt:target: (in category 'inline cacheing') ----- rewriteCallAt: callSiteReturnAddress target: callTargetAddress "Rewrite a call instruction to call a different target. This variant is used to link PICs in ceSendMiss et al, and to rewrite cached primitive calls. Answer the extent of the code change which is used to compute the range of the icache to flush." <var: #callSiteReturnAddress type: #usqInt> | callDistance | "self cCode: '' inSmalltalk: [cogit disassembleFrom: callSiteReturnAddress - 10 to: callSiteReturnAddress - 1]." false ifTrue: [self assert: callTargetAddress >= cogit minCallAddress] ifFalse: [callTargetAddress >= cogit minCallAddress ifFalse: [self error: 'linking callsite to invalid address']]. callDistance := (callTargetAddress - callSiteReturnAddress) signedIntToLong. objectMemory byteAt: callSiteReturnAddress - 1 put: (callDistance >> 24 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 2 put: (callDistance >> 16 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 3 put: (callDistance >> 8 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 4 put: (callDistance bitAnd: 16rFF). + self assert: (self callTargetFromReturnAddress: callSiteReturnAddress) signedIntToLong = callTargetAddress. - self assert: (self callTargetFromReturnAddress: callSiteReturnAddress) = callTargetAddress. "self cCode: '' inSmalltalk: [cogit disassembleFrom: callSiteReturnAddress - 10 to: callSiteReturnAddress - 1]." ^5! Item was changed: ----- Method: CogIA32Compiler>>rewriteInlineCacheAt:tag:target: (in category 'inline cacheing') ----- rewriteInlineCacheAt: callSiteReturnAddress tag: cacheTag target: callTargetAddress "Rewrite an inline cache to call a different target for a new tag. This variant is used to link unlinked sends in ceSend:to:numArgs: et al. Answer the extent of the code change which is used to compute the range of the icache to flush." <var: #callSiteReturnAddress type: #usqInt> | callDistance | "self cCode: '' inSmalltalk: [cogit disassembleFrom: callSiteReturnAddress - 10 to: callSiteReturnAddress - 1]." false ifTrue: [self assert: callTargetAddress >= cogit minCallAddress] ifFalse: [callTargetAddress >= cogit minCallAddress ifFalse: [self error: 'linking callsite to invalid address']]. callDistance := (callTargetAddress - callSiteReturnAddress) signedIntToLong. objectMemory byteAt: callSiteReturnAddress - 1 put: (callDistance >> 24 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 2 put: (callDistance >> 16 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 3 put: (callDistance >> 8 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 4 put: (callDistance bitAnd: 16rFF); byteAt: callSiteReturnAddress - 6 put: (cacheTag >> 24 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 7 put: (cacheTag >> 16 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 8 put: (cacheTag >> 8 bitAnd: 16rFF); byteAt: callSiteReturnAddress - 9 put: (cacheTag bitAnd: 16rFF). + self assert: (self callTargetFromReturnAddress: callSiteReturnAddress) signedIntToLong = callTargetAddress. - self assert: (self callTargetFromReturnAddress: callSiteReturnAddress) = callTargetAddress. "self cCode: '' inSmalltalk: [cogit disassembleFrom: callSiteReturnAddress - 10 to: callSiteReturnAddress - 1]." ^10! Item was changed: ----- Method: Cogit>>generateClosedPICPrototype (in category 'initialization') ----- generateClosedPICPrototype "Generate the prototype ClosedPIC to determine how much space as full PIC takes. When we first allocate a closed PIC it only has one or two cases and we want to grow it. So we have to determine how big a full one is before hand." | headerSize | numPICCases := 6. "stack allocate the various collections so that they are effectively garbage collected on return." self allocateOpcodes: numPICCases * 7 bytecodes: 0. self compileClosedPICPrototype. self computeMaximumSizes. headerSize := self sizeof: CogMethod. + closedPICSize := headerSize + (self generateInstructionsAt: methodZoneBase + headerSize). - closedPICSize := methodZone roundUpLength: headerSize + (self generateInstructionsAt: methodZoneBase + headerSize). firstCPICCaseOffset := endCPICCase0 address - methodZoneBase. cPICCaseSize := endCPICCase1 address - endCPICCase0 address. + cPICEndSize := closedPICSize - (numPICCases - 1 * cPICCaseSize + firstCPICCaseOffset). + closedPICSize := methodZone roundUpLength: closedPICSize - cPICEndSize := closedPICSize - (numPICCases - 1 * cPICCaseSize + firstCPICCaseOffset) "self cCode: '' inSmalltalk: [| end | end := self outputInstructionsAt: methodZoneBase + headerSize. self disassembleFrom: methodZoneBase + headerSize to: end - 1. self halt]"!

1 0

Re: [squeak-dev] new Cog VMs available [please read]
by Eliot Miranda 23 Sep '11

23 Sep '11

2011/9/22 Stéphane Rollandin <lecteur(a)zogotounga.net> > > I want to see >> C stack backtraces from these VMs whenever they crash. >> > > Here is one :) > Brilliant! Found the bug!! Thanks sooo much!! > Stef > > > > -- best, Eliot

1 1

Headless Image: a Riddle
by Mircea Filip Lungu 22 Sep '11

22 Sep '11

Here is a quick riddle for you: The Context: - os: debian - vm: cog - image: the image from the pier site, in which I updated to the latest version of the pier packages. Pier runs on port 8087. If I run the following line: ~/coglinux/bin/squeak x.image the image starts with no error and port 8087 is open. If I run the following line: ~/coglinux/bin/squeak -nodisplay -nosound x.image the image just blocks and the port 8087 is not open. do you have any idea what could be the reason? I tried with all the possible parameter combinations: (-headless, -vm-display-none) Thanks, M.

6 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev September 2011