Vm-dev February 2009

vm-dev@lists.squeakfoundation.org

23 participants
29 discussions

#pragma export on/off
by Eliot Miranda 20 Feb '09

20 Feb '09

Hi All, anyone know what platform this pragma is aimed at, and whether we still really, really need it? It is the source of the bulk of my warnings in the cog interpreter and I'd love to nuke it. E.

5 8

problem compiling latest sources for mac VM
by Esteban Lorenzano 19 Feb '09

19 Feb '09

I tried to compile de VM with latest sources from squeakvm.org. I followed all the readme instructions, and I needed to drop Squeak3D files and export info. However, I still have this error when linking: >> cd /Users/MAC/Desktop/Dev/Mars >> /Developer/usr/bin/gcc-4.0 -arch i386 -isysroot >> /Developer/SDKs/MacOSX10.4u.sdk >> -L/Users/MAC/Desktop/Dev/Mars/build/Development >> -F/Users/MAC/Desktop/Dev/Mars/build/Development >> -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks >> -filelist >> "/Users/MAC/Desktop/Dev/Mars/build/SqueakVMUNIXPATHS.build/Development/Squeak >> VM Universal.build/Objects-normal/i386/Squeak VM Opt.LinkFileList" >> -mmacosx-version-min=10.4 -framework CoreFoundation -framework Carbon >> -framework OpenGL -framework AGL -framework QuickTime -framework >> CoreAudio -framework AudioToolbox -framework IOKit -framework >> Foundation -framework Cocoa -prebind -o >> "/Users/MAC/Desktop/Dev/Mars/build/Development/Squeak VM >> Opt.app/Contents/MacOS/Squeak VM Opt" >> Undefined symbols: >> "_primitiveFailFor", referenced from: >> _primitiveFailFor$non_lazy_ptr in sqVirtualMachine.o >> "_reestablishContextPriorToCallback", referenced from: >> _reestablishContextPriorToCallback$non_lazy_ptr in sqVirtualMachine.o >> "_internalIsImmutable", referenced from: >> _internalIsImmutable$non_lazy_ptr in sqVirtualMachine.o >> "_classAlien", referenced from: >> _classAlien$non_lazy_ptr in sqVirtualMachine.o >> "_sendInvokeCallbackStackRegistersJmpbuf", referenced from: >> _sendInvokeCallbackStackRegistersJmpbuf$non_lazy_ptr in >> sqVirtualMachine.o >> "_getStackPointer", referenced from: >> _getStackPointer$non_lazy_ptr in sqVirtualMachine.o >> "_sqAllocateMemory", referenced from: >> _readImageFromFileHeapSizeStartingAt in interp.o >> "_classUnsafeAlien", referenced from: >> _classUnsafeAlien$non_lazy_ptr in sqVirtualMachine.o >> "_internalIsMutable", referenced from: >> _internalIsMutable$non_lazy_ptr in sqVirtualMachine.o >> ld: symbol(s) not found >> collect2: ld returned 1 exit status >> "_primitiveFailFor", referenced from: >> _primitiveFailFor$non_lazy_ptr in sqVirtualMachine.o >> "_reestablishContextPriorToCallback", referenced from: >> _reestablishContextPriorToCallback$non_lazy_ptr in sqVirtualMachine.o >> "_internalIsImmutable", referenced from: >> _internalIsImmutable$non_lazy_ptr in sqVirtualMachine.o >> "_classAlien", referenced from: >> _classAlien$non_lazy_ptr in sqVirtualMachine.o >> "_sendInvokeCallbackStackRegistersJmpbuf", referenced from: >> _sendInvokeCallbackStackRegistersJmpbuf$non_lazy_ptr in >> sqVirtualMachine.o >> "_getStackPointer", referenced from: >> _getStackPointer$non_lazy_ptr in sqVirtualMachine.o >> "_sqAllocateMemory", referenced from: >> _readImageFromFileHeapSizeStartingAt in interp.o >> "_classUnsafeAlien", referenced from: >> _classUnsafeAlien$non_lazy_ptr in sqVirtualMachine.o >> "_internalIsMutable", referenced from: >> _internalIsMutable$non_lazy_ptr in sqVirtualMachine.o >> ld: symbol(s) not found >> collect2: ld returned 1 exit status Any idea what I missed? Thanks, Esteban

2 1

[Fix][Unix] 64-bit issue in ioSetCursorARGB()
by Bert Freudenberg 19 Feb '09

19 Feb '09

Hi Ian, someone found a bug using big cursors on a 64 bit system. I naively neglected to use pointerForOop() when casting an oop to a pointer ... In platforms/unix/vm-display-X11/sqUnixX11.c replace (char *)cursorBitsIndex with (char *)pointerForOop(cursorBitsIndex) That trivial fix is in the olpc branch, and confirmed working: http://dev.sugarlabs.org/ticket/380#comment:3 Please add to the trunk :) - Bert -

1 0

headerTypeBytes oddity
by Igor Stasenko 19 Feb '09

19 Feb '09

A headerTypeBytes ivar used in Interpreter, but initialized only once during its lifetime - in readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset), and with same constants: headerTypeBytes at: 0 put: BytesPerWord * 2. "3-word header (type 0)" headerTypeBytes at: 1 put: BytesPerWord. "2-word header (type 1)" headerTypeBytes at: 2 put: 0. "free chunk (type 2)" headerTypeBytes at: 3 put: 0. "1-word header (type 3)" I think this initialization could be put into static var declaration, in #declareCVarsIn: aCCodeGenerator var: #headerTypeBytes declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'. then we don't have to pollute already complex #readImageFromFile:... method with odd stuff like this. It maybe not worth much attention for Squeak VM, but for Hydra, i found that this ivar placed into Interpreter struct (which means that each instance of interpreter will having separate headerTypeBytes). There are tons of ivars in ObjectMemory and Interpreter and its hard to track all, which worth keeping on a per-interpreter basis :) -- Best regards, Igor Stasenko AKA sig.

3 6

Memory management in HydraVM
by Igor Stasenko 18 Feb '09

18 Feb '09

Hello list, until now, i never examined how OS-specific routines sqAllocateMemory, sqGrowMemoryBy .. working, and in Hydra everything worked just well, without problems so far for two images.. Eventually, i tried to find a way how to deallocate the heap for an interpreter which is no longer running (if image quits, or fatal error in interpreter, or even on C exception) and found that i can't free memory for specific interpreter instance, because sqReleaseMemory() having no arguments. :) And by getting deeper, i found that memory management must be completely redesigned, because Hydra will unable to work with Interpreters > 2..4. For all platforms, if it supports virtual memory management, an sqAllocateMemory() function reserves a huge chunk of address space for a potentially big object memory heap, while reserving initially small amount of physical memory (enough to fit image in it + some extra space). This approach works well for single image, but not for multiple :( For instance, in win32 port, there is a constant which defines a total amount of address space reserved for a single heap: #define MAX_VIRTUAL_MEMORY 512*1024*1024 which means that first image heap takes 512Mb address space, second one - another 512Mb and if i remember correctly, in win32 process not allowed to reserve more than 2Gb address space, which means that when we try to run 3rd or 4th image, we having high probability that OS will reject to allocate any more address space. In any way, even if limit is 4Gb (max 32 bit address space), we still have a maximum number of about 8 interpreters. Not mentioning the address space used for C heap, kernel, many .dlls etc etc. and inevitable address space segregation. Also, i found that sqGrowMemoryBy(), sqShrinkMemoryBy(), sqMemoryExtraBytesLeft() using static variables, and there is high risk that if VM will use them in both direction (grow/shrink), it could lead to crash. This, of course can be fixed easily, by holding a memory state for each instance of interpreter separately, but this is not a cure for a problem with address space. It looks like, that Hydra will require a sophisticated virtual memory management (since Hydra runs only on systems which supporting threads, i think we can assume that OS gives us the way to manage virtual memory as well). I'd like to hear your advice, what strategy works best for it? Also, if you know about any tech-docs describing such strategies or libraries which enable to manage virtual memory efficiently - let me know. Shall the memory manager give small address space regions for each interpreter instance, and then if some image tends to grow bigger - relocate it into a different memory space with higher number of pages reserved for it? Is it safe to relocate an object memory when it is in working state (not running, because we obviously will request a relocation of object memory when current heap size will become too small to fit object memory in it)? The C code (in primitives/plugins) does not holding direct object pointers - thanks that we having a moving GC :) So i think it is doable.. -- Best regards, Igor Stasenko AKA sig.

2 2

Slow Unix socket write()s?
by Andreas Raab 18 Feb '09

18 Feb '09

Folks - I've been doing a bit of load-testing on our servers and thing that surprised me was that even in moderate load tests the VM appears to be spending some 20-30% of its total execution time in Socket>>primSocket:sendData:startIndex:count:. This is roughly at a throughput of 10Mbit so nothing spectacular and a long ways before we hit our bandwidth limits. Given that the primitive in the Unix VM appears to be a vanilla call to write() I cannot possibly imagine what could cause this to take that much time. Also, all of these sends are guarded so socketSendDone: returned true prior to calling the send function (socketSendDone: takes about 2% total time in the profiles). Has anyone seen similar behavior or has an idea on how to find out what is going on? If this is known write() behavior I would definitely consider putting this into a pthread for our servers. It is currently by far the biggest bottleneck that I can see. Any ideas? Cheers, - Andreas

3 5

FreeBSD's lang/squeak port vs 3.10-4
by Frank Shearar 17 Feb '09

17 Feb '09

In my continuing exploration around FreeBSD and 3.10-4 I thought I'd try Bert's "configure; make" on a fresh checkout of the repository. First, I must note that the lang/squeak port works out of the box. This uses the Squeak-3.9-7 VM. I tried to build the 3.10-4 VM on a 32 bit machine this time Just In Case. The attached make-configure.txt details the whole process of checking out the repository, making the bld directory, etc. Short version: /usr/home/frank/temp/platforms/unix/plugins/ClipboardExtendedPlugin/sqUnixEx tendedClipboard.c:31:21: error: X11/Xlib.h: No such file or directory /usr/home/frank/temp/platforms/unix/plugins/ClipboardExtendedPlugin/sqUnixEx tendedClipboard.c:32:22: error: X11/Xatom.h: No such file or directory /usr/home/frank/temp/platforms/unix/plugins/ClipboardExtendedPlugin/sqUnixEx tendedClipboard.c:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token *** Error code 1 Stop in /usr/home/frank/temp/bld/ClipboardExtendedPlugin. *** Error code 1 Stop in /usr/home/frank/temp/bld. Now Xlib.h and Xatom.h are in well-known locations (for FreeBSD, at least): frank@gont$ locate Xlib.h /usr/local/include/X11/Xlib.h frank@gont$ locate Xatom.h /usr/local/include/X11/Xatom.h This is exactly the same issue I had with building 3.10-4 on a 64-bit FreeBSD machine. Ah, I've just noticed _why_ (I think) the port works but not 3.10-4. The port's makefile says this: CONFIGURE_ARGS+= --libdir=${PREFIX}/share \ --without-quartz \ LDFLAGS="-L${LOCALBASE}/lib" \ CPPFLAGS="-I${LOCALBASE}/include" So a simple "configure; make; make install" doesn't work on FreeBSD. If this is OK (in other words, if you simply have to specify LDFLAGS and CPPFLAGS), then perhaps saying so in a README might be sufficient? frank

2 2

Best and latest VMs for Open Cobalt release?
by ed.boyce＠duke.edu 15 Feb '09

15 Feb '09

Everyone, Open Cobalt (http://opencobalt.org -- based on Open Croquet) is nearing its public alpha release. We would like to ship Open Cobalt with the most up-to-date VM possible on Mac, Linux and Windows, preferably at the same version on each. Ideally, that would probably mean 3.10.4 on every platform. Looking at http://squeak.org/Download/ and http://squeakvm.org, I see various latest version #'s available for the different platforms. One possible course of action I could take is do fresh builds on each platform from the current subversion sources. But before go through that exercise, I would like to ask the knowledgeable members of this list: 1) What is the latest STABLE version of the Squeak VM that is available for all three major platforms? 2) Is there any reason anyone can think of that this latest version would not be suitable and stable for Open Cobalt's alpha debut? This would include performance issues. If so, what is the most recent VM that would be suitable and stable? 3) We would like to expand the number of platforms that Cobalt is available on. Does anyone know of Squeak VM builds on platforms such as Solaris and FreeBSD that have the functioning openAL and openGL bindings necessary for Cobalt? All pointers, links, tarballs, and advice will be most appreciated. Best Regards, Ed Boyce for the Open Cobalt Project

4 9

Inclusion of the COM port patch for Unix/MacOS
by Séverin Lemaignan 15 Feb '09

15 Feb '09

Hello, This mail to know if I should do something to help on the reviewing/inclusion of the patch I submitted a couple of week ago regarding the support of named serial port on Unix machines. http://bugs.squeak.org/view.php?id=7266 Regards, Séverin Lemaignan

1 0

64bit FFI?
by Andreas Raab 14 Feb '09

14 Feb '09

Folks - Has anyone tried porting the FFI to 64 bit? I'm loosely considering using a 64bit VM for our servers but I do need the FFI (mostly for ODBC integration) and I've never looked at any of the ABIs. Alternatively, is it reasonable to try to use 64bit libs from within a 32bit Squeak VM? Thanks for any info! Cheers, - Andreas

7 33

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2009