Vm-dev December 2010

vm-dev@lists.squeakfoundation.org

42 participants
109 discussions

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Direct object pointers vs indirect ones pros and cons
by Igor Stasenko 26 Oct '11

26 Oct '11

Hi , all RoarVM using object tables, while Squeak VM using direct pointers for object. This is a basic element of VM design, and i wonder, how much impact it does on overall VM speed. Both variants having own advantages/disadvantages, while i think, that with good JIT an extra indirection could be almost insignificant. But having indirect pointers to objects opens quite sexy perspectives. Being able to freely choose object(s) location means that: - its quite easy to implement object memory paging (swapping between memory and disc), - place particular object(s) into special memory location (good for FFI, object pinning etc) - #become: is O(1), instead of O(heap size) The downside of indirect pointers is, of course, a higher memory traffic, which directly impacts all operations everywhere. What else? I'd like to know, what you thinking about it, and why Squeak VM, in particular, using direct object pointers? What are this choice based on? I'd like to know. Maybe i missing something. -- Best regards, Igor Stasenko AKA sig.

10 23

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

4.0.3.2196 for Unix
by Ian Piumarta 08 May '11

08 May '11

Folks, Source and binaries for Linux/i386, Darwin/i386 & Darwin/PPC now available. (Solaris, NetBSD and FreeBSD still at 3.11.3 until I get my kvm working again.) http://squeakvm.org/unix Enjoy! Ian Major changes since 3.11.3.2135: Generated sources rebuilt from VMMaker-dtl.169. Re-enabled MIDI support via ALSA on Linux. Broken locales should no longer cause line ends to go missing during copy and paste. Add support for "platform source version" primitive. Remove debugging beep on first clipboard copy under X11. Allow fully-qualified pathnames when loading modules. Bundle FreetypePlugin with source and binary releases. Various fixes for 64-bit cleanliness (many thanks to Dave Lewis). Add microsecond clock support. Fix launching from a menu under KDE. Fix --CFLAGS option in configure script. Serial plugin invalidates cached port names on close. Better handling of symlinks when looking for absolute path to VM binary.

5 12

[Cog] cmType ~= CMMethod
by Mariano Martinez Peck 01 Apr '11

01 Apr '11

Hi Eliot. I am having some asserts failing while running my tests. Most of them during the sweep phase of the GC. The two places where it fails is in - NewCoObjectMemory >> lastPointerWhileForwarding: oop if fails the assert: self assert: (coInterpreter cCoerceSimple: methodHeader to: #'CogMethod *') cmType = CMMethod. In different runs, the cmType answer me 1 (CMFree) - NewCoObjectMemory >> lastPointerOf: oop recordWeakRoot: recordWeakRoot "<Boolean>" and it fails in the same assert: self assert: (coInterpreter cCoerceSimple: methodHeader to: #'CogMethod *') cmType = CMMethod. In different runs, I got values 0 or 6. BTW....seing: initializeCogMethodConstants CMOpenPIC := 1 + (CMClosedPIC := 1 + (CMBlock := 1 +(CMMethod := 1 + (CMFree := 1)))) I cannot understand how can I get 0 or 6.... Anyway, my question is if you have a clue of what can be happening so that those asserts are failing. I am using Objects as methods, but normal objects (subclasses of ProtoObject). Thanks in advance, mariano

3 5

cog crash when running Pharo 1.2 tests
by Esteban Lorenzano 25 Jan '11

25 Jan '11

Hi, This is a continuation of a crash report by Igor (but I couldn't find the thread to reply properly, he). I tried running Pharo 1.2 tests using a cocoa cog compiled by my self (near 5.8b12 version, but with minor bugfixes), and the VM crashes with the info I'm pasting below. The crash occurs while executing TraitCompositionTest, which runs fine if it's run individually. btw... Pharo 1.1.1 tests runs correctly (some failures, some errors, but no crash :) ) best, Esteban (gdb) bt #0 0x0008f18c in longAt [inlined] () at /Users/MAC/Desktop/Dev/VM/cog-osx/platforms/Cross/vm/sqMemoryAccess.h:41314 #1 0x0008f18c in longAtPointer [inlined] () at /Users/MAC/Desktop/Dev/VM/cog-osx/platforms/Cross/vm/sqMemoryAccess.h:41314 #2 0x0008f18c in mapPointersInObjectsFromto (memStart=544259160, memEnd=547015536) at /Users/MAC/Desktop/Dev/VM/cog-osx/platforms/iOS/vm/../../../src/vm/gcc3x-cointerp.c:19156 #3 0x1f4d7330 in ?? () (gdb) call (int) printAllStacks() Process 0x1fb0b654 priority 40 0xbff664a4 I CompiledMethod(Object)>becomeForward: 547015488: a(n) CompiledMethod 0xbff664c8 M CompiledMethod>setSourcePointer: 547015488: a(n) CompiledMethod 0xbff664e4 M CompiledMethod>setSourcePosition:inFile: 547015488: a(n) CompiledMethod 0xbff6650c M CompiledMethod>putSource:fromParseNode:inFile:withPreamble: 547015488: a(n) CompiledMethod 0xbff66544 I Trait(TraitBehavior)>addTraitSelector:withMethod: 546943760: a(n) Trait 0xbff66570 M [] in Trait(TraitBehavior)>updateMethodDictionarySelector: 546943760: a(n) Trait 0xbff66590 M OrderedCollection>do: 546995828: a(n) OrderedCollection 0xbff665b4 M Trait(TraitBehavior)>updateMethodDictionarySelector: 546943760: a(n) Trait 0xbff665e0 I [] in Trait(TraitBehavior)>noteChangedSelectors: 546943760: a(n) Trait 0xbff66600 M [] in IdentitySet(Set)>do: 546964932: a(n) IdentitySet 0xbff66624 M Array(SequenceableCollection)>do: 546967168: a(n) Array 0xbff66640 M IdentitySet(Set)>do: 546964932: a(n) IdentitySet 0xbff66668 I Trait(TraitBehavior)>noteChangedSelectors: 546943760: a(n) Trait 0xbff66690 I Trait(TraitBehavior)>applyChangesOfNewTraitCompositionReplacing: 546943760: a(n) Trait 0xbff666b8 I Trait(TraitDescription)>applyChangesOfNewTraitCompositionReplacing: 546943760: a(n) Trait 0xbff666e0 I Trait>applyChangesOfNewTraitCompositionReplacing: 546943760: a(n) Trait 0xbff66708 I Trait(TraitBehavior)>setTraitComposition: 546943760: a(n) Trait 0xbff66738 I Trait class>named:uses:category:env: 526279012: a(n) Trait class 0xbff6676c I Trait class>named:uses:category: 526279012: a(n) Trait class 0xbff6679c I TraitCompositionTest(TraitsTestCase)>createTraitNamed:uses: 543518512: a(n) TraitCompositionTest 0xbff667c4 M TraitCompositionTest>testProvidedMethodBindingsWithConflicts 543518512: a(n) TraitCompositionTest 0xbff667dc M TraitCompositionTest(TestCase)>performTest 543518512: a(n) TraitCompositionTest 0xbff667f4 M [] in TraitCompositionTest(TestCase)>runCase 543518512: a(n) TraitCompositionTest 0xbff66814 M BlockClosure>ensure: 546942212: a(n) BlockClosure 0xbff66830 M TraitCompositionTest(TestCase)>runCase 543518512: a(n) TraitCompositionTest 0xbff6684c M [] in TestResult>runCase: 543379756: a(n) TestResult 0xbff66868 M BlockClosure>on:do: 546940640: a(n) BlockClosure 0xbff66888 M TestResult>runCase: 543379756: a(n) TestResult 0xbff668a4 M TraitCompositionTest(TestCase)>run: 543518512: a(n) TraitCompositionTest 0xbff668c0 M TestRunner>runTest: 543237552: a(n) TestRunner 0xbff668dc M [] in TestRunner>runSuite: 543237552: a(n) TestRunner 0xbff66914 M [] in OrderedCollection(Collection)>do:displayingProgress:every: 543380248: a(n) OrderedCollection 0xbff66934 M OrderedCollection>do: 543380248: a(n) OrderedCollection 0xbff6696c I [] in OrderedCollection(Collection)>do:displayingProgress:every: 543380248: a(n) OrderedCollection 0xbff66990 M [] in ProgressInitiationException>defaultMorphicAction 543926492: a(n) ProgressInitiationException 0xbff5e3c0 M BlockClosure>on:do: 543927148: a(n) BlockClosure 0xbff5e3f0 I [] in ProgressInitiationException>defaultMorphicAction 543926492: a(n) ProgressInitiationException 0xbff5e410 M BlockClosure>ensure: 543927012: a(n) BlockClosure 0xbff5e43c I ProgressInitiationException>defaultMorphicAction 543926492: a(n) ProgressInitiationException 0xbff5e45c I MorphicUIManager>progressInitiationExceptionDefaultAction: 543926724: a(n) MorphicUIManager 0xbff5e478 M ProgressInitiationException>defaultAction 543926492: a(n) ProgressInitiationException 0xbff5e494 M UndefinedObject>handleSignal: 525336580: a(n) UndefinedObject 0xbff5e4b4 M MethodContext(ContextPart)>handleSignal: 543861016: a(n) MethodContext 0xbff5e4d0 M ProgressInitiationException(Exception)>signal 543926492: a(n) ProgressInitiationException 0xbff5e4f0 I ProgressInitiationException>display:at:from:to:during: 543926492: a(n) ProgressInitiationException 0xbff5e524 I ProgressInitiationException class>display:at:from:to:during: 526266692: a(n) ProgressInitiationException class 0xbff5e558 I ByteString(String)>displayProgressAt:from:to:during: 528298688: a(n) ByteString 0xbff5e594 I OrderedCollection(Collection)>do:displayingProgress:every: 543380248: a(n) OrderedCollection 0xbff5e5c0 I OrderedCollection(Collection)>do:displayingProgress: 543380248: a(n) OrderedCollection 0xbff5e5f0 I [] in TestRunner>basicRunSuite:do: 543237552: a(n) TestRunner 0xbff5e610 M BlockClosure>ensure: 543926280: a(n) BlockClosure 0xbff5e634 I TestRunner>basicRunSuite:do: 543237552: a(n) TestRunner 0xbff5e65c I TestRunner>runSuite: 543237552: a(n) TestRunner 0xbff5e678 M TestRunner>runAll 543237552: a(n) TestRunner 0xbff5e698 I PluggableButtonMorph>performAction 543287688: a(n) PluggableButtonMorph 0xbff5e6b4 M [] in PluggableButtonMorph>mouseUp: 543287688: a(n) PluggableButtonMorph 0xbff5e6d8 M Array(SequenceableCollection)>do: 543379612: a(n) Array 0xbff5e700 I PluggableButtonMorph>mouseUp: 543287688: a(n) PluggableButtonMorph 0xbff5e724 I PluggableButtonMorph(Morph)>handleMouseUp: 543287688: a(n) PluggableButtonMorph 0xbff5e740 M MouseButtonEvent>sentTo: 543379572: a(n) MouseButtonEvent 0xbff5e75c M PluggableButtonMorph(Morph)>handleEvent: 543287688: a(n) PluggableButtonMorph 0xbff5e778 M PluggableButtonMorph(Morph)>handleFocusEvent: 543287688: a(n) PluggableButtonMorph 0xbff5e7a0 M [] in HandMorph>sendFocusEvent:to:clear: 526727360: a(n) HandMorph 0xbff5e7bc M [] in PasteUpMorph>becomeActiveDuring: 527811092: a(n) PasteUpMorph 0xbff5e7d8 M BlockClosure>on:do: 543379520: a(n) BlockClosure 0xbff5e804 M PasteUpMorph>becomeActiveDuring: 527811092: a(n) PasteUpMorph 0xbff5e828 M HandMorph>sendFocusEvent:to:clear: 526727360: a(n) HandMorph 0xbff5e850 M HandMorph>sendEvent:focus:clear: 526727360: a(n) HandMorph 0xbff5e874 M HandMorph>sendMouseEvent: 526727360: a(n) HandMorph 0xbff5e898 M HandMorph>handleEvent: 526727360: a(n) HandMorph 0xbff5e8c4 M HandMorph>processEvents 526727360: a(n) HandMorph 0xbff5e8dc M [] in WorldState>doOneCycleNowFor: 535613652: a(n) WorldState 0xbff5e900 M Array(SequenceableCollection)>do: 525350276: a(n) Array 0xbff5e91c M WorldState>handsDo: 535613652: a(n) WorldState 0xbff5e938 M WorldState>doOneCycleNowFor: 535613652: a(n) WorldState 0xbff5e954 M WorldState>doOneCycleFor: 535613652: a(n) WorldState 0xbff5e970 M PasteUpMorph>doOneCycle 527811092: a(n) PasteUpMorph 0xbff5e990 I [] in Project class>? 533540648: a(n) Project class 531674612 s [] in BlockClosure>newProcess Process 0x205eef6c priority 50 0xbff5f950 I WeakArray class>finalizationProcess 526245700: a(n) WeakArray class 0xbff5f970 I [] in WeakArray class>restartFinalizationProcess 526245700: a(n) WeakArray class 0xbff5f990 I [] in BlockClosure>newProcess 543092368: a(n) BlockClosure Process 0x20078f84 priority 80 0xbff60970 M Delay class>handleTimerEvent 526251340: a(n) Delay class 0xbff60990 I Delay class>runTimerEventLoop 526251340: a(n) Delay class 537366032 s [] in Delay class>startTimerEventLoop 537366308 s [] in BlockClosure>newProcess Process 0x205b9cc8 priority 60 0xbff61950 I SmalltalkImage>lowSpaceWatcher 527615096: a(n) SmalltalkImage 0xbff61970 I [] in SmalltalkImage>installLowSpaceWatcher 527615096: a(n) SmalltalkImage 0xbff61990 I [] in BlockClosure>newProcess 542874604: a(n) BlockClosure Process 0x205ecb00 priority 60 0xbff628d0 M [] in Delay>wait 543083336: a(n) Delay 0xbff628f0 M BlockClosure>ifCurtailed: 547003416: a(n) BlockClosure 0xbff6290c M Delay>wait 543083336: a(n) Delay 0xbff62924 M InputEventPollingFetcher>waitForInput 526779328: a(n) InputEventPollingFetcher 0xbff62950 I InputEventPollingFetcher(InputEventFetcher)>eventLoop 526779328: a(n) InputEventPollingFetcher 0xbff62970 I [] in InputEventPollingFetcher(InputEventFetcher)>installEventLoop 526779328: a(n) InputEventPollingFetcher 0xbff62990 I [] in BlockClosure>newProcess 543083044: a(n) BlockClosure SmallInteger 0xc01 priority Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000c0d printProcessStack (aProcess=3073) at /Users/MAC/Desktop/Dev/VM/cog-osx/platforms/iOS/vm/../../../src/vm/gcc3x-cointerp.c:37340 37340 printNum(quickFetchIntegerofObject(PriorityIndex, aProcess)); The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the expression containing the function (printAllStacks) will be abandoned.

3 7

SqueakVM trunk is broken since late April
by Aleksej Saushev 20 Jan '11

20 Jan '11

Hello! I'm trying to build VM from source and run into this: Linking C executable squeakvm CMakeFiles/squeakvm.dir/tmp/local/squeak-vm/work/squeak-vm/platforms/Cross/vm/sqVirtualMachine.c.o: In function `sqGetInterpreterProxy': sqVirtualMachine.c:(.text+0x45e): undefined reference to `internalIsImmutable' sqVirtualMachine.c:(.text+0x468): undefined reference to `internalIsMutable' sqVirtualMachine.c:(.text+0x472): undefined reference to `primitiveFailFor' sqVirtualMachine.c:(.text+0x47c): undefined reference to `classAlien' sqVirtualMachine.c:(.text+0x486): undefined reference to `getStackPointer' sqVirtualMachine.c:(.text+0x490): undefined reference to `sendInvokeCallbackStackRegistersJmpbuf' sqVirtualMachine.c:(.text+0x49a): undefined reference to `reestablishContextPriorToCallback' sqVirtualMachine.c:(.text+0x4a4): undefined reference to `classUnsafeAlien' --- squeakvm --- Going back in past, I've found that this was broken in r2203, which introduced references to these symbols which in turn were never defined. Could anyone at least shed the light on what is going on? -- HE CE3OH...

2 5

new Cog VMs
by Eliot Miranda 15 Jan '11

15 Jan '11

Hi All, I've released a new version of Cog that has a substantially improved code generator along the lines of Peter Deutsch's HPS (VisualWorks) and various of Ian Piumarta's VMs. These all use a simple tecnique to identify constant references in bytecode and to support a register-based calling convention. While this does produce faster code it tends to accelerate low-level code much more than high-level code as you can see by the following benchmarks: SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691 StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192 192 - 691 / 6.91 -72% SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec' StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec' 931756141 - 753495217 / 7534952.17 -24% 128157989 - 64769127 / 647691.27 -98% SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript) 43406 - 47013 / 470.13 -7.67234594686576 The status of this code is essentially beta. The test suite runs the same on the new code generator as on the old, but I think there are still bugs because I get the occasional transient error. I am therefore very interested in any reproducible errors you can find. The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few other important changes: - a bug fix to bytecode<->native pc mappng that produced incorrect results for methods containing blocks with ^-returns in them. One symptom is incorrect highlighting of the pc in the debugger, althoguh symptoms could be much serious. - jitting interpreted methods on backward branches. Currently any interpreted method that performs more than 20 backward branches will be considered for JIT compilation and if it is suitable (default, <= 60 literals) will be compiled to native code. - new callback support. I need to commit some changes to the Alien package to provide access to this but essentially the VM's callback support is now able to be ported to architectures with register-based calling conventions (ARM, PowerPC, SPARC etc). I'll try and get the Alien code released soon, and to back-port the changes to the standard VM before the end of the holiday. One thing that is still /not/ fixed is the lack of a SoundPlugin on win32. Apologies. I'll try and get a fix for this before the end of the holidays too, but time might be too tight. There are other priorities such as harmonising the standard and Cog VMs for the 4.2 release. best Eliot

4 7

Re: [Pharo-project] Waste of CPU Power by polling events?
by Eliot Miranda 11 Jan '11

11 Jan '11

On Thu, Nov 25, 2010 at 8:25 PM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > > On 2010-11-23, at 1:23 AM, Henrik Sperre Johansen wrote: > > > On 22.11.2010 22:08, Guido Stepken wrote: > >> Need additional: > >> > >> isOnMouseOverEvent > >> isMouseGestureEvent > >> isTouchGestureEvent > > You could try checking out how the iOS code does support for complex > events. > > It's of course somewhat apple-specific, but hey, would be nice to have > the same image-side representation and handling of touch-based events if > possible. > > Apple is very very notification &event callback oriented in their iOS > platform. It sleeps until you touch, then you get a touch event, you process > and go back to sleep. Heck if your startup time takes too many seconds Apple > nails you. > > For Squeak on iOS I take the touch data place on a queue and signals the > event semaphore. When the squeak image polls for the event we > turn the touch data into a complex event and pass it back, then is > processed by the Smalltalk code to turn into synthetic mouse events. (or > something). > > For keyboard entry, we take the key input data and turn into synthetic > keystroke events, and again signal the semaphore and put on a queue for > later when > the Smalltalk code wakes up and calls getnextevent to see what's up. > > I'm not sure if anyone mentioned the other issue is that the polling loop > also deals with doing the morphic redrawing so it runs a cycle of doing I > think it is > 50 iterations a second. > > For WikiServer which doesn't show a squeak UI I could cut that back to > doing a cycle every second or so. > > Oh and yet one more thing, the clock tick is yet another issue, some > platforms assume they can run an interrupt 1000 a second (or more) to ensure > the VM is responsive to Delay being correctly woken up to the microsecond. > "PS here I am over simplify the issue & complexity of the issue" but on > underpowered hardware the issues of how ioRelinquishProcessorForMicroseconds > and the millisecond timer work become messy issues in relationship to CPU > usage. > Yes, we need to change this, but I think one has to change the background process and/or nothing to run behavior. In the VW VM the VM disables the heartbeat and enters some blocking call when there's nothing to do. Squeak runs the background process which calls a primitive that sleeps for a short time. The former is much better. If a delay is active as the VM does to sleep it schedules a wakeup event or supplies a timeout so that it blocks until input is available or the next delay. We could still keep the background process and do something similar to VW, disabling the heartbeat until after the relinquish, and factoring the delay into the relinquish timeout. Also the heartbeat already has facilities to change its frequency, so one could modify things to slow down the heartbeat, again ensuring that it ticks before the next delay expiry. What approach (not necessarily from the above) appeals to you John? best Eliot > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > >

5 10

Image freeze because handleTimerEvent and Seaside process gone?!
by Adrian Lienhard 04 Jan '11

04 Jan '11

Hi all, We've been experiencing an "interesting" problem: the image freezes and does not response to HTTP requests anymore after it has been running for days. Here some basic information about our setup: Squeak VM 4.0.3-2202 compiled with gcc 4.3.2 PharoCore 1.1 OS Debian Lenny amd64 (CPUs are 4 Intel Xeon E5530 2.40GHz) - We have never seen the problem with the Squeak VM 3.9-9 and Squeak 3.9 on the identical machine and with the same application source (modulo some adaptations to make it run on Pharo). - We run the VM with -mmap 512m -vm-sound-null -vm-display-null, and the UI process is suspended (Project uiProcess suspend) - VM does not hog the CPU and memory usage is normal - The meantime between failure is several weeks and we haven't managed to reproduce the problem - The application mainly serves HTTP requests. When the image does not receive requests for some time we send it a STOP signal, when a request comes in it is sent a CONT signal. - lsof shows TCP *:9093 (LISTEN) TCP server:9093->server:46930 (CLOSE_WAIT) Below is a GDB backtrace and the Smalltalk stacks from an image that was frozen (the VM had been running for almost 100 hours): ============================================================= (gdb) bt #0 0x08072020 in ?? () #1 <signal handler called> #2 0xb766f5e0 in malloc () from /lib/libc.so.6 #3 <function called from gdb> #4 0xb76c50c8 in select () from /lib/libc.so.6 #5 0x08071063 in aioPoll () #6 0xb778bb8d in ?? () from /usr/lib/squeak/4.0.3-2202//so.vm-display-null #7 0x000003e8 in ?? () #8 0x997b5a34 in ?? () #9 0xbfe7cb28 in ?? () #10 0x08074575 in ioRelinquishProcessorForMicroseconds () Backtrace stopped: frame did not save the PC (gdb) call printCallStack() -1719969228 >idleProcess -1719969320 >startUp -1740134028 BlockClosure>newProcess $3 = -1755344892 (gdb) call (int) printAllStacks() Process -1719969228 >idleProcess -1719969320 >startUp -1740134028 BlockClosure>newProcess Process -1740113860 >finalizationProcess -1740113952 >restartFinalizationProcess -1740113532 BlockClosure>newProcess Process -1740134424 SmalltalkImage>lowSpaceWatcher -1740134516 SmalltalkImage>installLowSpaceWatcher -1740134300 BlockClosure>newProcess Process -1719451488 Delay>wait -1719451580 BlockClosure>ifCurtailed: -1719451704 Delay>wait -1719451796 InputEventPollingFetcher>waitForInput -1740126940 InputEventFetcher>eventLoop -1740127032 InputEventFetcher>installEventLoop -1740126816 BlockClosure>newProcess Process -1719557780 UnixOSProcessAccessor>grimReaperProcess -1740113624 BlockClosure>repeat -1740113716 UnixOSProcessAccessor>grimReaperProcess -1740117340 BlockClosure>newProcess [omitted many newlines between output above] ============================================================= What is striking from the above process listing is that two processes are missing: the handleTimerEvent process and the Seaside process (that is, the TCP listener loop). How comes these processes vanished? This may be related to Pharo or to the Squeak VM. Has anybody else seen this problem? Any idea how to debug/fix this issue is very much appreciated! Cheers, Adrian CCed to pharo-dev since this may be related to Pharo; please respond on the squeak-vm list

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev December 2010