Vm-dev June 2011

vm-dev@lists.squeakfoundation.org

35 participants
141 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

Squeak VM port to Google Native Client
by Yoshiki Ohshima 19 Feb '12

19 Feb '12

Hello, I'm playing with Google Native Client a bit and made a port of Squeak VM to it. It is far from complete (even the state where backspace or Cmd-p etc. does not work, sound does not work, etc.), It now reached to the state where I can say the basic part of it is working. The source code is available at: http://github.com/yoshikiohshima/NaClSqueak . Also, f you have Google Chrome 11 beta available, try to turn on the Native Client on (by typing "about:flags" into the title bar) and access: http://tinlizzie.org/~ohshima/squeak/squeak.html (The first try may take some time.) - It is gnuify-ed but we're still learning the JIT situation of NaCl. So, it' need some work to port Cog. - The image data is embedded as a C array in this executable. You can remove EMBEDDED_IMAGE_FILE flag off, and comment/uncomment the corresponding part of squeak.html, it can load the image separately via XMLHttpRequest of the browser. - There is some strange issue when you do fast drag the system window. - As you can see, the source code is derived from the Unix VM. It was hard for me to write some CMake stuff to set it up for the cross compilation. A help to merge it back to the Unix code would be greatly appreciated. - If Google takes over the world and all apps become a Native Client (may be even other browsers^^;), this port may be useful^^; -- Yoshiki

9 25

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

Call for papers: SMALLTALKS 2011
by jannik.laval 09 Jul '11

09 Jul '11

CALL FOR PAPERS SMALLTALKS 2011 5th International Conference on Smalltalk Technologies Research Track: Call for Papers November 3th - 5th, 2011 Important dates: Submission (Hard Deadline): August 22th, 2011 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: September 23th, 2011. Camera Ready Submission: October 7th, 2011. --------------------------------------------------------------------------------- Conference Location: Universidad Nacional de Quilmes (Argentina) The Smalltalks series of conferences (www.fast.org.ar) is a lively forum on Smalltalk-based software technologies that brings together more than 200 people from both academia and industry for a period of three days. Past editions of Smalltalks have included many high-quality presentations from industry and research. These contributions have shown interesting applications of Smalltalk, advances in the Smalltalk language, didactic uses of Smalltalk and so on. Similar to last year, Smalltalks 2011 will include a dedicated research track. We welcome submissions to this research track presenting original scientific contributions to, or using, Smalltalk in general. Topics of interest include, but are not restricted to: - Aspects, Aspect Languages and Applications. - Ambient Intelligence, Ubiquitous / Pervasive Computing and Embedded Systems. - Compilation Technology, Optimization, Virtual Machines. - Educational Material. - Language Engineering, Extensions. - Model Driven Engineering / Development. - Meta-Modeling, Reflection and Meta-programming. - Programming in the Large, Design, Architectures and Components. - Programming Environments, Browsers, User Interfaces, UI Frameworks. - Source-code analysis and manipulation (Static analysis, refactoring, type inference, metrics). - Team Management. - Testing, Extreme Programming / Practices. - Web Services, Internet Applications, Event-driven Programming. - Experience Reports. Important dates: Submission (Hard Deadline): August 22th, 2011 (Argentinian time: UTC/GMT -3 hours). Notification of acceptance: September 23th, 2011. Camera Ready Submission: October 7th, 2011. Papers: Papers should be written in English, in PDF-format and should not exceed 15 pages (including references and figures), using the Elsevier journal format. Templates for LaTeX formats can be found at http://www.elsevier.com/wps/find/authorsview.authors/elsart Papers must be submitted through the EasyChair submission web site at https://www.easychair.org/conferences/?conf=smalltalks2011 The accepted papers will be digitally available on the conference website. We are currently negotiating a special edition of a journal for which the best papers will get invited. Papers submitted must not have been previously published and must not be under review for publication elsewhere. Papers must strictly adhere to submission guidelines. If you have questions, please send an e-mail to Jannik Laval and Andy Kellens to smalltalks2011-chair(a)fast.org.ar. Program Committee -------------------------- - Gonzalo Zabala (Universidad Abierta Interamericana, Argentina) - Hernan Wilkinson (Universidad de Buenos Aires, Argentina) - Serge Stinckwich (Institut de recherche pour le developppement, France) - Mircea Lungu (University of Bern, Switzerland) - Tudor Girba (Sw-eng. Software Engineering GmbH, Switzerland) - Johan Fabry (DCC, Universidad de Chile, Chile) - Luc Fabresse (Ecole des Mines Douai, France) - Marcus Denker (INRIA Lille, France) - Coen De Roover (Vrije Universiteit Brussel, Belgium) - Damien Cassou (Hasso-Plattner-Institut, Potsdam, Germany) - Gilad Bracha (SAP Labs, Palo Alto, USA) - Noury Bouraqadi (Ecole des Mines Douai, France) - Alexandre Bergel (DCC, Universidad de Chile, Chile) - Gabriela Arevalo (Universidad Nacional de Quilmes, Argentina) Program Chairs -------------------- Andy Kellens (Vrije Universiteit Brussel, Belgium) Jannik Laval (INRIA Lille/LABRI Bordeaux, France) --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

1 1

Building stack VM on windows fails
by Igor Stasenko 05 Jul '11

05 Jul '11

There are two undefined symbols: Linking C executable results/StackVM.exe Creating library file: results/libStackVM.dll.a CMakeFiles/StackVM.dir/objects.a(gcc3x-interp.c.obj): In function `returnAsThrou ghCallbackContext': c:/hudson/workspace/StackWin32/cog/src/vm/gcc3x-interp.c:34699: undefined refere nce to `siglongjmp' CMakeFiles/StackVM.dir/objects.a(sqWin32Prefs.c.obj): In function `CreatePrefsMe nu': c:/hudson/workspace/StackWin32/cog/platforms/win32/vm/sqWin32Prefs.c:374: undefi ned reference to `recordPrimTraceFunc' - siglongjmp (it is found however in cointerp.c so JIT-flavored VMs don't have this problem, but not stack ones) The recordPrimTraceFunc() are used like following: #if STACKVM extern sqInt recordPrimTraceFunc(); #endif ... #if STACKVM if (recordPrimTraceFunc()) AppendMenu(hMenu, MF_STRING | MF_UNCHECKED, ID_DUMPPRIMLOG, TEXT("Dump recent primitives")); #endif again, it is defined in cogit.h/.c but obviously not in stack interpreter, since stack not using cogit. Maybe you meant #if !STACKVM ? Then it makes sense. -- Best regards, Igor Stasenko AKA sig.

2 2

Re: Cog JIT crashing
by Igor Stasenko 01 Jul '11

01 Jul '11

resending, because original attached .png was too big On 30 June 2011 19:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > with latest updates, a Cog VMs simply crashing quickly after image startup. > > I strongly suspect that the bug in jit, because stack VMs built using > same VMMaker sources are working well. > You can check the: > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Carbon/ > vs > https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Carbon/ > > > of course, first thing which i suspected is that my merge was bad, so > i also tried to build VM using VMMaker.oscog-eem.88 > but it also crashing with same symptoms and always in same place (in > ceSendsupertonumArgs() , with rcvr argument containing non-oop (-36 , > sometimes 0, sometime -24) ) > > See the screenshot in attachment. > > I also checked win32 Cog build.. same result: immediate crash after > selecting an image to open. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

2 3

Tracking Hudson builds
by Igor Stasenko 01 Jul '11

01 Jul '11

I am thinking, how is better to track Hudson builds. Currently VM reports a build by taking a VMMaker package version. But it is incomplete information: - there is no evidence which sources been used and which configuration of CMakeVMMaker been used. Hudson fetching everything from git, so using git hash number is a complete pointer to the sources. But in addition, i need to specify which configuration been used (since there are many of them). Actually i think that the more information we put, the easier it would be to track down, which VM are used. So, my question, what is your preferences? Because currently 'Cog 4.0.0' as well as 'VMMaker-foo-bar.xyz' says almost nothing :) -- Best regards, Igor Stasenko AKA sig.

2 2

Squeak Port for Android: Update
by Dimitry Golubovsky 30 Jun '11

30 Jun '11

Phil, Phil wrote: > Thanks for your efforts on this, working quite nicely (at least for the image I can get to run :-) on my Honeycomb tablet. One question I do have: are you aware of any changes > that need to be made to or things to watch out for when running other images? I've tried about half a dozen images (pre- and post-Cog) but they all hang while loading resulting > in a force close. However, the image you provided based on the earlier work of Andreas, works as expected. Thanks for the update. Can you post the tiny benchmark result as in http://code.google.com/p/squeakvm-tablet/wiki/TinyBenchmark so I could add it to the table? It is good to hear that Android 3 can run it. I am not sure what can be done with newer images: I tried some as well and got same results (program hangs). Keep in mind that this is 3.9 VM. > Also an FYI if you weren't already aware: the recently released NDKr5c appears to have finally addressed the issue that prevented building with the latest NDK. I am trying to find time to play with recent Pharo, VMmaker and Cog (Mariano Peck has a good review of the VM internals in his blog which I am going to use as reference material) to do the same trick of "turning the event loop inside out" as Andreas did to the classic VM used in this port, and then to use ndk5, newer images, better platform code management, etc. This may result in a more universal embeddable Squeak VM. I think that whatever was done with the original port has shown that Squeak may be used on Android tablets pretty well. Next step is to get in sync with the current VM sources. Thanks. -- Dimitry Golubovsky Anywhere on the Web

3 3

VM Maker: VMMaker-oscog-IgorStasenko.91.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 Jun '11

30 Jun '11

Igor Stasenko uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-oscog-IgorStasenko.91.mcz ==================== Summary ==================== Name: VMMaker-oscog-IgorStasenko.91 Author: IgorStasenko Time: 30 June 2011, 4:52:32 am UUID: d8240a62-1c3a-4322-8917-61a229d662ce Ancestors: VMMaker-oscog-IgorStasenko.90, VMMaker.oscog-eem.89 - merge with eem.89 - added fix to initialize pool vars before they added to code generator

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2011