Vm-dev May 2012

vm-dev@lists.squeakfoundation.org

37 participants
74 discussions

Reference counting
by Damien Cassou 09 May '12

09 May '12

Hi, how does the VM handle reference counting for the garbage collector? When is the counter increased/decreased? Best -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

2 1

Illumos port
by Colin Putney 08 May '12

08 May '12

Hi folks, As was mentioned in the Squeak Board minutes, I've been working on getting Squeak running on SmartOS. (SmartOS is a newish distribution of Illumos, which is a fork of OpenSolaris, which is apparently no longer open, now that Oracle owns it. Anyway, it's a flavour of Solaris.) Attached is a patch that lets me build the VM and open an image in a SmartOS zone. I ran into a few issues, which I'll detail below: 1) I tried to do a proper autoconf check for the existence of headers such as <sys/sockio.h> and <sys/ucontext.h>, but I ran afoul of very strange behaviour from the libtool script that my regenerated configure script created. (Geez, how many levels of code generation do these GNU guys think is healthy?) I was able to create the config.h file that I wanted, but then linking didn't work anymore. For now I've just used the __sun__ preprocessor definition (apparently automatically defined by the compiler) for conditional compilation. 2) It looks like the image runs ok, but when I try to connect a VNC client (SmartOS has no GUI), the VM receives a SIGPOLL/SIGIO signal and exits. Fixing that probably requires more significant changes than I've made so far, so if anybody has suggestions on how to tackle it, I'd love to hear them. If there's some other method of submitting the patch that would be more convenient of the maintainers, I'm happy to do that instead. Colin

3 7

Problem building CogMT vm with CogMTCocoaIOSConfig
by Mariano Martinez Peck 08 May '12

08 May '12

Hi guys. If I do: CogMTCocoaIOSConfig new "generateForDebug;" generateSources; generate. I get this error: [ 36%] Building C object CMakeFiles/CogMTVM.dir/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/src/vm/cogit.c.o <command-line>: warning: "COGMTVM" redefined <command-line>: warning: this is the location of the previous definition /Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/src/vm/cogit.c:18:22: error: cointerp.h: No such file or directory This is wrong because the file it should be searching is cointerpmt.h: and not cointerp.h. So what I think it is happening is that somehow we are missing the -DCOGMTVM=1 we are sending while compiling. So then Cog thinks it is a regular Cog (not MT) and hence tries to include cointerp.h. Moreover, this warning is suspiciuous: <command-line>: warning: "COGMTVM" redefined Of course, if I use CogCocoaIOSConfig instead of CogMTCocoaIOSConfig, it works fine. Any ideas? I will see if I find something more. -- Mariano http://marianopeck.wordpress.com

2 1

VM is being buil without debug info?
by Mariano Martinez Peck 08 May '12

08 May '12

Hi guys. I am building a VM with debug mode: CogCocoaIOSConfig new generateForDebug; generateSources; generate. So the flags it should use are: '-g3' '-O0' '-DDEBUGVM=1' Now I am debugging a crash with gdb but bt shows just '??': Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0000080c 0x1f4b0f77 in ?? () (gdb) bt #0 0x1f4b0f77 in ?? () #1 0x1f4c2d6e in ?? () #2 0x1f4ac10e in ?? () #3 0x1f4adc81 in ?? () #4 0x1f4b9196 in ?? () #5 0x1f4b922e in ?? () #6 0x1f4b7966 in ?? () #7 0x1f4b4b8f in ?? () #8 0x1f4b491f in ?? () #9 0x1f4b4532 in ?? () #10 0x1f4b463b in ?? () #11 0x1f400cce in ?? () #12 0x1f4b45eb in ?? () #13 0x1f4b44b7 in ?? () #14 0x1f4007c8 in ?? () #15 0x1f4a9646 in ?? () #16 0x1f4b723b in ?? () #17 0x1f400cce in ?? () #18 0x1f4b71ea in ?? () #19 0x1f4b6b22 in ?? () #20 0x1f4a956d in ?? () (gdb) any idea? does it mean that the VM is being built without the debug info? thanks -- Mariano http://marianopeck.wordpress.com

3 7

Help/advice tracking down a squeak-vm regression
by Alex Bradbury 08 May '12

08 May '12

Hi all, As some of you may know, MIT Scratch does not work on the latest squeak-vm (4.4.7-2353). This is unfortunate, because that's the version of squeak-vm packaged in Debian wheezy and thanks to the recent GPLv2 relicensing of Scratch this incompatibility is the only thing preventing Scratch from getting in to Debian's package archive before the 'freeze' for the next version version (wheezy). Miriam Ruiz and others have done some debugging at <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471927>. The symptoms are that when opening the Scratch image, you just get a black window and 100% CPU usage. See Miriam's posts for straces and the section of code that loops forever. In a situation like this, I'd normally just do a binary search through the changes between the working 4.0.3 and broken 4.4.7 using git bisect. However, given that the VM code is automatically generated by VMM (is the Slang source even version controlled?) I can't see an easy way to do that. I'd really appreciate any help anyone can offer in debugging this issue, Many thanks, Alex

4 9

Re: [Vm-beginners] From Window to Compiler evaluate:
by Igor Stasenko 08 May '12

08 May '12

On 7 May 2012 18:37, Chris Cunnington <smalltalktelevision(a)gmail.com> wrote: > How does the vm pass a string to the compiler in object memory to be > evaluated? > > The VM works with the OS so that a window collects a string in UTF-8 or > Unicode and send it to the compiler in the object memory in RAM. > > Date today > > becomes > > Compiler evaluate: 'Date today' > > I see in MicroSqueak > > Interpreter>>primitiveKbdPeek > > sends things to the stack. I understand something called 'the stack' they > way understand unicorns. > > But is it true to say that the stack is a step on the way to the compiler in > RAM? > > Window-->characters-->vm-->primitiveKbdPeek-->stack-->object > memory-->compiler--> Compiler evaluate:-->bytecodes > > Then, after bytecodes have been generated, Interpreter>>interpret can do > what it does. The output can make a trip back to the window going back the > way it came. > > How accurate or inaccurate is this description? > Well, speaking of unicorns.. ;) At OS level, VM listens for events, like key push/release, mouse move(s) etc. It translates incoming events to own format and puts it into internal queue. Then smalltalk side walking by, like a postman and picks up the queued events, during its walk it decodes them and dispatching to own subsystem(s), like MVC or Morphic, which ends up in some widget which represents text editor. Once user pressing cmd-D (or alt-d) a text editor rides an unicorn (with a cart loaded by typed text) right to the compiler ;) > Thanks, > Chris > _______________________________________________ > VM-beginners mailing list > VM-beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners -- Best regards, Igor Stasenko.

1 0

Re: [Pharo-project] Can OSProcess functionality be implemented using FFI instead of plugin?
by Eliot Miranda 08 May '12

08 May '12

On Sun, May 6, 2012 at 9:14 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2012/5/6 Igor Stasenko <siguctua(a)gmail.com>: > > On 6 May 2012 17:08, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > wrote: > >> 2012/5/6 Guillermo Polito <guillermopolito(a)gmail.com>: > >>> > >>> > >>> On Sun, May 6, 2012 at 2:16 PM, Esteban Lorenzano <estebanlm(a)gmail.com > > > >>> wrote: > >>>> > >>>> <snip> > >>>> I'm more worried about having all-platforms-specific-stuff inside > image... > >>>> but we can mitigate that with fuel, and making loadable packages when > >>>> running the image... I don't know, I'm just thinking while writing, > so, this > >>>> is probably stupid :) > >>>> > >>> > >>> Just think how many times you took a development image and used it in > >>> several platforms. At least I don't. Same happened when I used > Eclipse. I > >>> didn't share my eclipses between systems. Even, I had several eclipse > >>> installations with their own plugins (just like images, hehe). > >>> > >>> Probably with jenkins, metacello, and kernel/bootstrap we can generate > >>> distributions per platform (With the possibility of an all-in-one > >>> distribution for the ones who like that). > >>> > >>> Guille > >> > >> Yes, I understand that we can live without this feature... > >> - If we can reconstruct images easily (one of the goal of Pharo) - I > >> mean not only code, but any object (eventually with Fuel) > >> - If we solve the bootstrap problem (or if we can still prepare an > >> image for cross platform startup) > >> - If we don't forget to always talk (send messages) thru an abstract > >> layer, and never directly name the target library, > >> > >> Since I didn't have all these tools in the past, I were forced to use > >> development images across different platform a lot, and yes, it was > >> not following the mainstream rules (a la "we can reconstruct all from > >> scratch") but damn powerful. > >> For deploying applications, it also is very powerful and cheap. > >> Personally, I would feel sore to lose it. > >> > > > > But look at the root of what we are talking about: N bytes in VM > > versus M bytes in image to support certain functionality. > > I think if you need it, you will make sure that those bytes is there > > and properly packaged with you application. > > > > Unfortunately, it's more than moving code... > What I mean is that when I need to pass an O_NONBLOCK flag to a FFI > call, it's going to be a problem because I have to know how this > information is encoded on each and every platform I want to support. > But there are solutions to this which mean you *don't* have to know. I wrote a prototype for VisualWorks that maps a SharedPool to these externally defined variables. Here's how it works. For each group of C constants, e.g. i/o constants, one populates a subclasss of SharedPoolForC with the variables one wants to define, and in a class-side method one defines the set of include files per platform that one should pull in to evaluate the constants. SharedPoolForC has code in it to automatically generate a C program, and compile it, e.g. to provide a shared library/dll for the current platform. The C program is essentially a name-value dictionary that maps from the abstract name #O_NONBLOCK to the size and value for a particular platform. SharedPoolForC also contains code to load the shared library/dll, extract the values and update the pool variables automatically. The deployment scheme is as follows, at start-up the system asks each SharedPoolForC subclass to check the platform and see if the platform has changed. If it hasn't changed, nothing needs to happen. If it has changed the system attempts to locate the shared library/dll for the current platform (the platform name is embedded in the dll's name), and update the pool variables from that dll, raising an exception if unavailable (and the exception could be mapped into a warning or an error to suit). So to deploy e.g. a one-click one needs to generate the set of dlls fort the platforms one wants to deploy on. The development scheme is simply to run a method on the SharedPoolForC when one adds some class variables and/or changes the set of include files which turns the crank, generating, compiling and loading the C file to get the value(s) for the new variable(s). An alternative scheme would generate a program that would print e.g. STON, which could be parsed or evaluated to compute the values. This would have the advantage that the definitions of the values are readable and editable by mere humans. So I think I'd discard the shared library/dll approach and keep it simple. At least, in C code, I just care about the symbolic information and > have a relatively portable sentence. > To me that's one of the highest hurdle with FFI, because this is the > kind of complexity I wish I never cared of. > That's just a flavour of #define/#ifdef hell. > It can be worse if you want to interface with IPC (which has lot's of > different flavours). > Same for functions defined by macros that just use machine specific > structure layout... We can no longer use these structures as opaque > handles. > > > You can ship your product and use it on multiple platforms with ease, > > granted that appropriate platform-specific code is loaded into your > > image. > > With distribution using VMs it's a bit different story: it is a > > barrier with high entry cost. Especially if you think about all those > > RPMs, which is controlled by third-party maintainers. It is not that > > easy to directly control it, and much much slower in case if you need > > to deal with some problems. > > > > I agree on the principle, I always prefer to develop in FFI than hack > the VM, I'm far far more efficient on the former. > Nonetheless, I don't think FFI can magically solve all our problems. > In certain ways it can make them worse. > > Nicolas > > >> Nicolas > >> > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- best, Eliot

2 1

[ENH] Returning from context with sender == nil
by Igor Stasenko 07 May '12

07 May '12

Just an idea.. currently, when returning from bottom context, which has no sender, VM generates a message #cannotReturn: You can checking by invoking: (thisContext privSender: nil). ^ 5 which is fine, except that i think we can extend this behavior for use in cases when we leaving the normal "smalltalk" execution back to some C caller, namely: - callbacks - a "message send" from C upon return from method (or block) , an interpreter always checks if sender of a context (a caller context) is valid MethodContext instance. i am thinking about very small change, which will provide additional functionality: - if context's sender in non-valid MethodContext, but instance of SmallInteger, then we just assume that given smallinteger is an address of C function which should be called (by stripping the tag bit of course). The function is of kind: void (fn*) (sqInt returnValue). i.e. upon discovering sender is smallint, an interpreter will call this function with return value as argument. As an option for additional safety, we can avoid using pure function address in small integer instance, but instead use a registry of valid addresses (so that smallint will be an index in a table, where cool hackers can register own "No-return" handlers). Then VM should check if sender is small integer, and if it is a valid registered index in "No-return" handlers table, and if its ok, then call that function, otherwise, do as usual and raise "cannot return exception". You may argue, that same functionality can be achieved by using special primitive(s). Which is true for callbacks, since we definitely control the callback entry, and on return we can invoke special primitive to return back to C caller. But thinking about future, imagine that we have an API in VM, similar to Objective-C, which allows you to send a message to any object and get a result: /* C code */ resultOop = vmSend(receiver, selector, 3 /*num args */ , arg1, arg2, arg3); here, we cannot control the execution , since potentially a C caller may pick any receiver , any selector, so the entry point, unlike from callbacks are not controllable at smalltalk side. However if we use the proposed trick, upon return from the context, we can clearly detect that it is time to return to C caller and handle it accordingly. What you think? -- Best regards, Igor Stasenko.

3 3

VM Maker: VMMaker.oscog-eem.160.mcz
by commits＠source.squeak.org 06 May '12

06 May '12

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.160.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.160 Author: eem Time: 5 May 2012, 3:33:23.184 pm UUID: c9667f5a-0f6f-464a-99a7-d4ef8e7821b0 Ancestors: VMMaker.oscog-eem.159 Avoid assigning to a block argument in inlineCaseStatement- BranchesIn:localizingVars: Fix a comment. =============== Diff against VMMaker.oscog-eem.159 =============== Item was changed: ----- Method: StackInterpreter>>marriedContext:pointsTo:stackDeltaForCurrentFrame: (in category 'frame access') ----- marriedContext: spouseContext pointsTo: anOop stackDeltaForCurrentFrame: stackDeltaForCurrentFrame + "This is a helper for primitiveObjectPointsTo so it *does not* check the frameContext field because that is an implicit self-reference not present in the state ." - "This is a helper for primitiveObjectPointsTo so it *does not* check the frameContext field because that is an implicit self-reference not present in the stale ." | theFP thePage theSP rcvrOffset | <inline: false> <var: #theFP type: #'char *'> <var: #thePage type: #'StackPage *'> <var: #theSP type: #'char *'> <var: #rcvrOffset type: #'char *'> theFP := self frameOfMarriedContext: spouseContext. theFP = framePointer ifTrue: [theSP := stackPointer + (stackDeltaForCurrentFrame * BytesPerWord)] ifFalse: [thePage := stackPages stackPageFor: theFP. theSP := self findSPOf: theFP on: thePage]. (objectMemory isIntegerObject: anOop) ifTrue: "Check stack and instruction pointer fields." [(anOop = (objectMemory integerObjectOf: (self stackPointerIndexForFrame: theFP WithSP: theSP)) or: [anOop = (self externalInstVar: InstructionPointerIndex ofContext: spouseContext)]) ifTrue: [^true]] ifFalse: "Check method and sender fields, avoiding unnecessarily reifying sender context." [anOop = (self frameMethodObject: theFP) ifTrue: [^true]. (self isBaseFrame: theFP) ifTrue: [anOop = (self frameCallerContext: theFP) ifTrue: [^true]] ifFalse: [((self frameHasContext: (self frameCallerFP: theFP)) and: [anOop = (self frameContext: (self frameCallerFP: theFP))]) ifTrue: [^true]]]. "Now check receiver, temps and stack contents" rcvrOffset := self frameReceiverOffset: theFP. [theSP <= rcvrOffset] whileTrue: [anOop = (stackPages longAt: theSP) ifTrue: [^true]. theSP := theSP + BytesPerWord]. "Finally check stacked receiver (closure field or duplicate of receiver) and arguments" theSP := theFP + FoxCallerSavedIP + BytesPerWord. rcvrOffset := theFP + (self frameStackedReceiverOffset: theFP). [theSP <= rcvrOffset] whileTrue: [anOop = (stackPages longAt: theSP) ifTrue: [^true]. theSP := theSP + BytesPerWord]. ^false! Item was changed: ----- Method: TMethod>>inlineCaseStatementBranchesIn:localizingVars: (in category 'inlining') ----- + inlineCaseStatementBranchesIn: aCodeGen localizingVars: varsList + | maxTemp usedVars v exitLabel | - inlineCaseStatementBranchesIn: aCodeGen localizingVars: varsList - - | stmt sel newStatements maxTemp usedVars exitLabel v | maxTemp := 0. + parseTree nodesDo: + [:n | + n isCaseStmt ifTrue: + [n cases do: + [:stmtNode | | newStatements stmt meth | + (stmt := stmtNode statements first) isSend ifTrue: + [(meth := (aCodeGen methodNamed: stmt selector)) isNil ifFalse: + [(meth hasUnrenamableCCode + or: [meth args notEmpty]) ifFalse: + [meth := meth copy. + meth hasReturn + ifTrue: + [exitLabel := meth unusedLabelForInliningInto: self. + meth exitVar: nil label: exitLabel. + labels add: exitLabel] + ifFalse: [exitLabel := nil]. - parseTree nodesDo: [ :n | - n isCaseStmt ifTrue: [ - n cases do: [ :stmtNode | - stmt := stmtNode statements first. - stmt isSend ifTrue: [ - sel := stmt selector. - (aCodeGen methodNamed: sel) ifNotNil: - [:meth| - (meth hasUnrenamableCCode - or: [meth args notEmpty]) ifFalse: [ - meth := meth copy. - meth hasReturn ifTrue: [ - exitLabel := meth unusedLabelForInliningInto: self. - meth exitVar: nil label: exitLabel. - labels add: exitLabel. - ] ifFalse: [ exitLabel := nil ]. - meth renameLabelsForInliningInto: self. + labels addAll: meth labels. + newStatements := stmtNode statements asOrderedCollection allButFirst. + exitLabel ifNotNil: + [newStatements addFirst: (TLabeledCommentNode new + setLabel: exitLabel + comment: 'end case')]. + newStatements + addFirst: meth asInlineNode; + addFirst: (TLabeledCommentNode new setComment: meth selector). + stmtNode setStatements: newStatements]]]]]]. + usedVars := (locals , args) asSet. + 1 to: maxTemp do: + [:i | + v := 't' , i printString. + (usedVars includes: v) ifTrue: + [self error: 'temp variable name conflicts with an existing local or arg']. + locals addLast: v]. - meth labels do: [ :label | labels add: label ]. - newStatements := stmtNode statements asOrderedCollection. - newStatements removeFirst. - - exitLabel ~= nil ifTrue: [ - newStatements addFirst: - (TLabeledCommentNode new - setLabel: exitLabel comment: 'end case'). - ]. - - newStatements addFirst: meth asInlineNode. - newStatements addFirst: - (TLabeledCommentNode new setComment: meth selector). - stmtNode setStatements: newStatements. - ]. - ]. - ]. - ]. - ]. - ]. - usedVars := (locals, args) asSet. - 1 to: maxTemp do: [ :i | - v := ('t', i printString). - (usedVars includes: v) ifTrue: [ self error: 'temp variable name conflicts with an existing local or arg' ]. - locals addLast: v. - ]. - "make local versions of the given globals" + varsList do: + [:var | + (usedVars includes: var) ifFalse: + [locals addFirst: var asString]]! - varsList do: [ :var | - (usedVars includes: var) ifFalse: [ locals addFirst: var asString ]. - ].!

1 0

64 bits (was: Squeak Oversight Board minutes – 5/01/12)
by Bert Freudenberg 04 May '12

04 May '12

On 04.05.2012, at 10:16, Casey Ransberger wrote: > Below. > > On May 4, 2012, at 12:55 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > (huge snip, context is in the rest of the thread) > >> IMHO, that's not only a question of handling huge image, there might >> be an advantage for some applications with more speed-efficient object >> format like for example: >> >> 1) immediate double values (like VW SmallDouble) >> 2) immediate characters >> 3) 32 bit integers, signed or unsigned - that would simplify a lot of >> handlings, and greatly accelerate LargeInteger arithmetic which is >> still based on 8bit operations on our 64 bits machines ! >> >> Nicolas > > Mr. Cellier, a.k.a. "nice," is supporting my point flawlessly. I threw out a couple of reasons to design in particular directions as a way to illustrate that the road to 64-bit is not well defined for us yet, I did so to point out that just bitwidth isn't the only important consideration, and he's pointed out that even the arguments I presented as examples *grossly* underthink the issues involved. > > To be clear: I'm quite passionate about seeing a 64-bit Cog walk, and I think it's something to strive for, but there are some wonderful people using this VM with different goals, and perhaps unfortunately, learning what we all need from a 64-bit VM is likely to be a longish conversation. > > In any event, though, #doIt! Make it work, if you want it, and then the rest of the world will be quite out of your way while you're using what you've made. At least in Squeak, we can do stuff like that. > > CC Eliot because it's his baby and I don't even know what I'm talking about:) At least, he can probably speak to the challenges around 64-bit support as well as absolutely anyone else around. > > > Casey IMHO the most urgent need is to make the 32 bit VM compile on a 64 bit machine. Running 64 bit images would be nice, too, but the problem most users run into right now is that they just cannot easily run their current image on that shiny new box. - Bert -

7 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2012