Vm-dev July 2007

vm-dev@lists.squeakfoundation.org

15 participants
15 discussions

can't get amd64 squeak install working
by Timmy Douglas 20 Jul '07

20 Jul '07

I'm reposting here from the main squeak list because no one there seems to be able to help me. I am using the latest subversion tree to build the source but it appears the vm-display-X11 part isn't working correctly. If I run headless it seems to start without errors but I have no way of checking anything. I'm using a standard ubuntu install with gnome 2.18.1..and the default window manager... whatever that is. metacity? >> timmy@timmy-desktop:~/src/squeak/seaside-test/squeak-svn-source/platforms/unix/bld$ ./squeak ../../../../Squeak3 >> 0alpha.7121.image >> X Error: BadValue (integer parameter out of range for operation) >> Major opcode of failed request: 78 >> Minor opcode of failed request: 0 >> Serial number of failed request: 7 > > Sorry, I don't know what is causing this. XInternAtoms might be. BadValue: Some numeric value falls outside the range of values accepted by the request. Unless a specific range is specified for an argument, the full range defined by the argument's type is accepted. Any argument defined as a set of alternatives can generate this error. (gdb) 2036 XInternAtoms(stDisplay, selectionAtomNames, SELECTION_ATOM_COUNT, False, selectionAtoms); (gdb) Breakpoint 3, xError (dpy=0x736d70, evt=0x7fff40a13940) at /home/timmy/src/squeak/seaside-test/squeak-svn-source/platforms/unix/vm-display-X11/sqUnixX11.c:1753 1753 { (gdb) 1755 XGetErrorText(dpy, evt->error_code, buf, sizeof(buf)); (gdb) 1753 { (gdb) 1755 XGetErrorText(dpy, evt->error_code, buf, sizeof(buf)); (gdb) 1756 fprintf(stderr, (gdb) X Error: BadValue (integer parameter out of range for operation) Major opcode of failed request: 78 Minor opcode of failed request: 0 Serial number of failed request: 7 1766 } (gdb) print selectionAtoms $21 = {18446744073709551599, 18446744073709551562, 18446744073709551589, 18446744073709551571, 18446744073709551586, 18446744073709551606, 18446744073709551563, 18446744073709551600} then I get a lot of Xerrors printed before it resumes execution. My gdb doesn't seem to support threads beceause 'info threads' is blank. here is another run: Breakpoint 5, initWindow (displayName=<value optimized out>) at /home/timmy/src/squeak/seaside-test/squeak-svn-source/platforms/unix/vm-display-X11/sqUnixX11.c:2036 2036 XInternAtoms(stDisplay, selectionAtomNames, SELECTION_ATOM_COUNT, False, selectionAtoms); (gdb) print stDisplay $23 = (Display *) 0x736d70 (gdb) print *stDisplay $24 = <incomplete type> (gdb) print selectionAtomNames $25 = {0x2b32917b67ec "CLIPBOARD", 0x2b32917b67f6 "CUT_BUFFER0", 0x2b32917b6802 "TARGETS", 0x2b32917b680a "MULTIPLE", 0x2b32917b6813 "UTF8_STRING", 0x2b32917b681f "COMPOUND_TEXT", 0x2b32917b682d "TIMESTAMP", 0x2b32917b6837 "SQUEAK_SELECTION"} (gdb) print SELECTION_ATOM_COUNT No symbol "SELECTION_ATOM_COUNT" in current context. (This is 8) (gdb) print False No symbol "False" in current context. (gdb) print selection selection selectionAtomNames selectionAtoms (gdb) print selectionAtoms $26 = {0, 0, 0, 0, 0, 0, 0, 0} (gdb) ptype Display type = struct _XDisplay { <incomplete type> } If you need more info just ask and I'll try to get it.

4 8

Suspend
by Michael Rueger 18 Jul '07

18 Jul '07

Hi all, Bert and I were discussing the implications of power usage (or rather non usage) of Squeak on the OLPC. IIRC Squeak still does some polling (event tickler?). This has also caused quite some pain for people running Squeak on a server: Squeak will always stay in the working set using a few percent CPU (=power!) constantly, even if it effectively has been idle for a long time. What would it take to change the VM and Squeak to make it truly event driven? Michael

4 6

32bit clean VM work.
by John M McIntosh 15 Jul '07

15 Jul '07

Some of you might know that David T. Lewis has been working on changes to the VM source to make it work fully within 32 or 64 bit address spaces. As we know the Squeak VM treated memory address which are unsigned values as signed integer values. This wrong usage of signed math in compare statments or do loops which would cause the VM to make an incorrect decision resulting in corrupted memory and causing the VM to crash. This issue would usually occur if you wanted to use 1GB of memory for your VM and the host operating system would then allocate memory for you above the 2GB boundary, or at say the 1.5GB boundary. Resulting either in an instant crash, or a crash much later when your memory needs caused the VM to grow over the 2GB boundary. Some fixes were done in the past to make the VM mostly run when fully over the 2GB boundary but at best they were insufficient patches. Over the last couple of days I reviewed David Lewis' changes, plus made some fixes, and revised the macintosh os-x support files, plus worked up some general test cases to see what happens when you run the macro bench marks below the 2GB boundary, crossing the 2GB boundary, and when the image is allocated at the 3GB boundary. This afternoon I'm pleased to say the VM passed all runs of my trivial test cases, so I have check in the Mac OS carbon source code changes and David's changes to the Mac OS source tree for further review. People wanting to build a VM should review the Mac OS build instructions to build a Mac OS carbon VM, or review the required changes to VMMaker as per the Carbon VM build readme to build a 32bit clean VM. I have not: (a) build a 64 bit VM and tested it. VM developers should consider the mmap call in the memory allocation routine, you can specify a suggested starting position. On OS-X I was able to chose 1GB, 1.5GB, 2GB and 3GB. I have not tested 64bit VMs at the 0x8000000000000000 boundary. I suspect you could allocate at the 0x7FFFFFFFF0000000 Then ask for 600MB of memory for the image. That would set the end of memory at 0x8000000015800000, 344MB over the negative sign boundary. (b) I have not tested or reviewed any of the external plugins for improper use of usqInt. (c) I have not confirmed the changes work with the Unix VM, or the Windows VM, I have no plans to do so. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

7 16

[Draft Article] Optimizing Contexts
by Matthew Fulmer 11 Jul '07

11 Jul '07

Cross-posted to: strongtalk-general(a)googlegroups.com vm-dev(a)lists.squeakfoundation.org exupery(a)lists.squeakfoundation.org news(a)lists.squeakfoundation.org comp.lang.smalltalk Hello lists. This is a draft of an article I am writing for an upcoming series at the Weekly Squeak. It is about optimizing context creation, I would like comments on its technical correctness, as well as suggestions for related content I should include. I would especially like to know if this article covers the way this is handled in systems I did not specifically research, such as Strongtalk, and Exupery, and non-smalltalk systems like Common Lisp, Erlang, Haskell, and OCaml, since this topic is not really specific to object-oriented systems. This will not be the first article of the series; however, the first two paragraphs are the preliminary series introduction. I put them in so that you can get an idea of what I am writing. Sections enclosed in ... tags are parts I am especially unsure of; I would appreciate comments (I used i tags, because my editor, vim, highlights the enclosed text when in HTML mode). Look forward to this appearing in the Weekly Squeak: http://news.squeak.org/ Thank you for your help, and enjoy the article! === Speeding Up Smalltalk Series, part 42: Context Optimizations === Ever since object-oriented systems became popular, they have had the image of being very easy to program, but very slow in terms of execution speed. This image and reality has plagued every popular object-oriented system, starting with Smalltalk in the 80's and continuing on to Java and Ruby today. However, this does not have to be the case. Early-bound languages have gotten much faster thanks to lots of research on compilers and computer architecture. Similarly, much research has been done on making late-bound object-oriented systems fast, both with software and with hardware. This research has not seen as much exposure as processor research, and so is probably less familiar to you. This series, "Speeding Up Smalltalk" attempts to summarize a lot of that research and present it for your enjoyment. Computation in Smalltalk and Self is done by sending messages to objects. This seemingly simple operation of sending a message is done so often and is so flexible that it is always the execution bottleneck in any implementation of Smalltalk or similar object-oriented system. Why is that? ---- Description of Context Objects ---- Every time a message is sent, four things happen: - A search is done through the message receiver for a method that has been sent. This was the topic of the previous article, and will not be discussed here. - A context object is allocated on the heap. - The context object is initialized and filled with: - local objects, including: - pointers to the message arguments - pointers for each local variable - pointers for temporary storage needed for intermediate results - A way to reference variables defined in other scopes. This is a property blocks have, but methods don't - In Smalltalk, by a pointer to the "home context" - In Self, by delegate slots to the enclosing context(s) - A return address at which to resume execution - Squeak does not need this, since every context has it's own PC, so when returning, the PC of the returned-to context is already in the right place. This is equivalent to a return address, since a child's return address is the parents PC. - A return context that will become current upon return - The newly-created context is made the "current" context for this thread/process In Squeak, MethodContexts and BlockContexts are subclasses of ContextPart. ContextPart has three instance variables: - sender: The context that sent the message being executed. This context will become current when the current context returns - pc: A pointer to the currently executing instruction - stackp: The pointer to the execution stack. The smalltalk virtual machine is a stack processor. local variables are stored in the indexed fields of the context. stackp keeps track of which OOP is at the top of the stack. For MethodContexts: MethodContext extends it with 3 instance variables, and a variable-sized area for holding the temporaries: - method: the CompiledMethod holding the code being executed - receiverMap: Something to do with the names of the variables. Not really sure - receiver: a pointer to "self", the receiver of the message. ---- Squeak optimization: Static Contexts ---- In Squeak, BlockContexts are partial closures (sometimes called static blocks/closures [3]). Rather than hold their own code and environment, BlockContexts piggyback off of another context/code pair. Home is the environment that the block piggybacks off of. This usually works, but there are some cases where this scheme will not work: - like what? Why not? I don't understand why this doesn't always work. Something to do with re-entrancy or circular references. Not sure why either is a problem. For BlockContexts: - nargs: the number of arguments that the block must be called with. - startpc: The index into <code>self home method</code> where the code for the block starts. - home: the home environment Squeak's NewCompiler has a different representation of blocks. These are full closures, storing their own code and environment. They are sometimes called dynamic closures to distinguish them from the above "static closures" [3]. They contain: - method: The code of the block (CompiledMethod2) - environment: Captured temps (ClosureEnvironment) ---- Squeak optimization: Context Recycling ---- To avoid having to create a new MethodContext on every message send, Squeak keeps a pool of pre-allocated MethodContexts, and simply fills one up when a new one is needed. To support this optimization, MethodContexts are only created with two sizes, rather than any size that they could support. The small size has room for a few temporaries, and the large size has room for a bunch [4] ---- VisualWorks optimization: Context Caches ---- The most natural way to store contexts is as a linked list of objects, but that does not map well to the hardware of many processors. Many processors (including all the Intel varieties) have several built-in instructions to mechanize the creation of stack frames, which are similar to context objects, but have several important differences. VisualWorks uses these native stack frames for most operations, meaning that context creation is identical to a C function send in many cases. Thus, the hardware stack acts as a stand-in for the context objects; this optimization is called a context cache. However, stack frames cannot handle context responsibilities beyond a single call and return; when more is needed, a context object must be allocated on the heap. The context object can either be a context in it's own right (a stable context), or act as a proxy to the hardware stack frame (hybrid context). There are several complications to this dual scheme; curious readers should refer to [5]. VW and Squeak does not use a stack of context frames; instead it uses a linked list of real context objects. This is easier, but perhaps slower. To save on allocation costs, contexts are cached and recycled for various method invocations. Not sure where to incorporate this There are three types of blocks: - open/clean blocks (pure function with no closure) - copying blocks - full blocks ---- Or you can cheat... ---- The most popular object-oriented languages (C++, Java) chose to dump the flexibility of blocks in exchange for runtime speed. These languages use a native stack frame without providing the escape mechanism of a context cache, so that blocks and other context behavior that does not follow stack principles is not supported. This is a tradeoff that eliminates a good deal of flexibility, and so will not be explored further. ---- Final words ---- Inlining solves many of the same problems as a Context cache does. If the method body is inlined into the caller, no new context need be created. However, inlining solves many more problems than just context elimination; I will dedicate an entire article to it. ---- References ---- - context recycling may be discussed in tims nublue book: http://www.rowledge.org/tim/squeak/OE-Tour.html - context caches are discussed in section 5.2.3 of http://www.kampjes.demon.co.uk/articles/exuperyDesign.pdf [3] add reference to squeak mailing list or Ian's something to discuss the difference between static and dynamic closures [4] Squeak Class comments of <code>InstructionStream</code>, <code>ContextPart</code>, <code> MethodContext</code>. and <code>BlockContext</code>. [5]: Context Management in VisualWorks 5i: http://wiki.cs.uiuc.edu/VisualWorks/DOWNLOAD/papers/oopsla99-contexts.pdf -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

1 0

linux 64bit vm running a 32 bit images - networking vm crash
by tom 01 Jul '07

01 Jul '07

hi, i am running a 64bit vm (elf64 / x86_64) linux, no i have no 32bit compat x11 libs and i dont want to have them... the vm crashes on any network operation, any clues? Program received signal SIGSEGV, Segmentation fault. 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 2902 header = longAt(oop); (gdb) bt #0 0x0000000000416711 in byteSizeOf (oop=-1398317376) at gnu-interp.c:2902 #1 0x00000000004a376d in primitiveResolverStartNameLookup () at .../platforms/unix/src/vm/intplugins/SocketPlugin/SocketPlugin.c:318 #2 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #3 0x0000000000416e76 in dispatchFunctionPointer (aFunctionPointer=0xaca75ec0) at gnu-interp.c:3953 #4 0x000000000042abb1 in interpret () at gnu-interp.c:7761 #5 0x0000000000415609 in main (argc=<value optimized out>, argv=0x7fff3fd1cce8, envp=<value optimized out>) ...platforms/unix/vm/sqUnixMain.c:1379 Segmentation fault 23308044 [] in >addressForName:timeout: 23308136 [] in Semaphore>critical: 23307768 BlockContext>ensure: 23307676 Semaphore>critical: 23306908 >addressForName:timeout: 23299436 >httpGetDocument:args:accept:request: 23303844 >httpGet:args:accept:request: 23303380 >httpGet:args:user:passwd: 23303012 MCHttpRepository>allFileNames 23302896 MCFileBasedRepository>allFileNamesOrCache 23302788 MCFileBasedRepository>readableFileNames 23302696 MCFileRepositoryInspector>refresh 23302540 MCFileRepositoryInspector>setRepository:workingCopy: 23302356 >repository:workingCopy: 23302264 MCFileBasedRepository>morphicOpen: 23302448 [] in MCWorkingCopyBrowser>openRepository 23302172 Object>ifNotNilDo: 23302080 MCWorkingCopyBrowser>openRepository 23301620 PluggableButtonMorph>performAction 23301436 PluggableButtonMorphPlus>performAction 23301528 [] in PluggableButtonMorph>mouseUp: 23301344 SequenceableCollection>do: 23301252 PluggableButtonMorph>mouseUp: 23301120 PluggableButtonMorphPlus>mouseUp: 23301028 Morph>handleMouseUp: 23300936 MouseButtonEvent>sentTo: 23300568 Morph>handleEvent: 23300476 Morph>handleFocusEvent: 23300660 [] in HandMorph>sendFocusEvent:to:clear: 23300752 [] in PasteUpMorph>becomeActiveDuring: 23300384 BlockContext>on:do: 23300292 PasteUpMorph>becomeActiveDuring: 23300016 HandMorph>sendFocusEvent:to:clear: 23299924 HandMorph>sendEvent:focus:clear: 23299832 HandMorph>sendMouseEvent: 23299344 HandMorph>handleEvent: 23293552 HandMorph>processEvents 23293668 [] in WorldState>doOneCycleNowFor: 23293460 SequenceableCollection>do: 23293368 WorldState>handsDo: 23293276 WorldState>doOneCycleNowFor: 23291300 WorldState>doOneCycleFor: 23291208 PasteUpMorph>doOneCycle 14434012 [] in >spawnNewProcess 14434196 [] in BlockContext>newProcess thanks in andvance ;) __________________________________ Kennt man wirklich jeden über 3 Ecken? Die Antworten gibt's bei Yahoo! Clever. www.yahoo.de/clever

11 23

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev July 2007