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
> All I can say is that I am impressed by the numbers it is really much
>> faster.
>> I still don't understand why I send this email with a subject say
>> IdentitySet because what I really need is a fast/large IdentityDictionary
>> :( Anyway, there's a place where we can use this LargeIdentitySet in Fuel
>> I think).
>>
>> So Levente, you say this is not possible to adapt this for dictionary?
>> can
>> we contact Eliot to provide such a primitive?
>>
>
> As promised, I uploaded my LargeIdentityDictionary implementation to
> http://leves.web.elte.hu/**squeak/**LargeIdentityDictionary.st<http://leves.web.elte.hu/squeak/LargeIdentityDictionary.st>.
> The numbers will be a bit worse compared to LargeIdentitySet, because of
> the lack of the primitive, but it's still 2-3x faster than other solutions
> (IdentityDictionary, PluggableIdentityDictionary, subclassing, etc). I'm
> about to propose this primitive with other improvements on the vm-dev list.
>
>
Hi Eliot/Levente. What is the status of this? Do we have already the new
primitive? If true, how can we adapt LargeIdentitySet to use such new
primitive?
Thanks!
>
> Levente
>
>
>> thanks
>>
>> On Fri, Dec 16, 2011 at 3:28 PM, Levente Uzonyi <leves(a)elte.hu> wrote:
>>
>> On Fri, 16 Dec 2011, Henrik Sperre Johansen wrote:
>>>
>>> On 16.12.2011 03:26, Levente Uzonyi wrote:
>>>
>>>>
>>>>
>>>>> How about my numbers? :)
>>>>>
>>>>> "Preallocate objects, so we won't count gc time."
>>>>> n := 1000000.
>>>>> objects := Array new: n streamContents: [ :stream |
>>>>> n timesRepeat: [ stream nextPut: Object new ] ].
>>>>>
>>>>> set := IdentitySet new: n.
>>>>> Smalltalk garbageCollect.
>>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "4949"
>>>>>
>>>>> set := LargeIdentitySet new.
>>>>> Smalltalk garbageCollect.
>>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "331"
>>>>>
>>>>> set := (PluggableSet new: n)
>>>>> hashBlock: [ :object | object identityHash * 4096 + object class
>>>>> identityHash * 64 ]; "Change this to #basicIdentityHash in Pharo"
>>>>> equalBlock: [ :a :b | a == b ];
>>>>> yourself.
>>>>> Smalltalk garbageCollect.
>>>>> [1 to: n do: [ :i | set add: (objects at: i) ] ] timeToRun. "5511"
>>>>>
>>>>>
>>>>> I also have a LargeIdentityDictionary, which is relatively fast, but
>>>>> not
>>>>> as fast as LargeIdentitySet, because (for some unknown reason) we don't
>>>>> have a primitive that could support it. If we had a primitive like
>>>>> primitive 132 which would return the index of the element if found or
>>>>> 0 if
>>>>> not, then we could have a really fast LargeIdentityDictionary.
>>>>>
>>>>>
>>>>> Levente
>>>>>
>>>>> Hehe yes, if writing a version fully exploiting the limited range,
>>>> that's
>>>> probably the approach I would go for as well.
>>>> (IAssuming it's the version at http://leves.web.elte.hu/**
>>>> squeak/LargeIdentitySet.st<htt**p://leves.web.elte.hu/squeak/**
>>>> LargeIdentitySet.st<http://leves.web.elte.hu/squeak/LargeIdentitySet.st>
>>>> >
>>>> )
>>>>
>>>> Mariano commented in the version at http://www.squeaksource.com/**
>>>> FuelExperiments <http://www.squeaksource.com/**FuelExperiments<http://www.squeaksource.com/FuelExperiments>>
>>>> that it's
>>>>
>>>> slow for them, which I guess is due to not adopting #identityHash calls
>>>> to
>>>> #basicIdentityHash calls for Pharo:
>>>> ((0 to: 4095) collect: [:each | each << 22 \\ 4096 ]) asSet size -> 1
>>>> So it basically uses 1 bucket instead of 4096... Whoops. :)
>>>>
>>>> Uploaded a new version to the MC repository which is adapted for Pharo,
>>>> on the same machine my numbers were taken from, it does the same test
>>>> as I
>>>> used above in 871 ms. (181 with preallocation).
>>>>
>>>>
>>> Cool. One more thing: in Squeak the method using primitive 132 directly
>>> was renamed to #instVarsInclude:, so now #pointsTo: works as expected. If
>>> this was also added to Pharo, then the #pointsTo: sends should be changed
>>> to #instVarsInclude:, otherwise Array can be reported as included even if
>>> it wasn't added.
>>> I'll upload my LargeIdentityDictionary implementation to the same place
>>> this evening, since it's still 2-3 factor faster than other solutionts
>>> and
>>> there seem to be demand for it.
>>>
>>>
>>> Levente
>>>
>>>
>>> Cheers,
>>>> Henry
>>>>
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com>
>>
>>
>
--
Mariano
http://marianopeck.wordpress.com
Hi Esteban:
I just downloaded a Cog-Mac-Cocoa-blessed from: https://ci.lille.inria.fr/pharo/job/Cog-Mac-Cocoa-blessed/
It tells me, it is currently 19days old.
And it ignores the -headless parameter.
The old VM I used so far is from Jul 6th and does execute headless without problems.
I did not find the mail on the list that was naming the primitives to get more version infos out of the VMs, sorry.
The latest StackVM also got that problem, but it works with the version from July.
Is there actually something like -version on the command line to ask for the exact version infos?
I checked -help, which also offers a lot less info then it used to. It still mentions -headless, but misses the options below.
Best regards
Stefan
Missing help for commandline options:
-breaksel selector set breakpoint on send of selector
-eden <size>[mk] set eden memory to bytes
-leakcheck num check for leaks in the heap
-stackpages num use n stack pages
-codesize <size>[mk] set machine code memory to bytes
-sendtrace[=num] enable send tracing (optionally to a specific value)
-tracestores enable store tracing (assert check stores)
-cogmaxlits <n> set max number of literals for methods compiled to machine code
-cogminjumps <n> set min number of backward jumps for interpreted methods to be considered for compilation to machine code
-pathenc <enc> set encoding for pathnames (default: macintosh)
--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax: +32 2 629 3525
Hi,
I have found the origin of various crashes in the Squeak VM, which is related to the JPEGReadWriter2Plugin.
The hunt begun with Juan's Cuis 4.0 release, see the emails exchanged below and the description.
I have attached the fixed C source, but the fix should go in the VM sources, because the code is
generated as I see. Please include the fix in the VM sources.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 9:26 PM
Subject: Re: Cuis 4.0 crash on startup
Wow Páhi! This is great! Please send all this to the vm-dev mail list, and ask for it to be included (or directions to do it yourself).
It is my bug in the end... I wrote JPEGReadWriter2Plugin about 10 years ago...
Cheers,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
Replace the winbuild/src/JPEGReadWriter2Plugin/JPEGReadWriter2Plugin.c file with the attached file,
recompile the Squeak VM and Cuis 4.0 rocks. In the plugin there was a 1 off access in the formBits array.
Because the code is generated, it needs to be corrected in the VM sources.
How can I got there ?
Executing several times World buildMagnifiedBackgroundImage in Cuis 3.3 crashed the Squeak VM.
I exported the background image data, converted from JPEG to other format (BMP/PNG) and set the new
format image to World backgroundImageData:. Everything worked as expected.
I replaced the formBits array accesses in JPEGReadWriter2Plugin2.c with my routines, checking the indices
and reporting off-array access attempts. Then I fixed the places in the C source.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 12:47 PM
Subject: Re: Cuis 4.0 crash on startup
Great. Thanks. You might ask for help or directions in the vm-dev mail list. I'm sure that several people are at least aware of the bug.
Cheers,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
Thank you for your reply. I will dig into the issues with the Windows VM.
Regards,
Andras Pahi
----- Original Message -----
From: Juan Vuletich (mail lists)
To: Páhi András
Sent: Thursday, April 26, 2012 11:59 AM
Subject: Re: Cuis 4.0 crash on startup
Hi Páhi,
There is some problem with that Windows VM, not limited to Cuis. If you google "Squeak VM 4.1.1 windows crash" you'll find many results, for example http://bugs.squeak.org/view.php?id=7585http://bugs.squeak.org/bug_view_advanced_page.php?bug_id=7686 and http://bugs.squeak.org/view.php?id=7523 .
I'm not involved in the development of the Windows VM, all I can do is recommend using Cog until this is fixed somehow.
Regards,
Juan Vuletich
Quoting Páhi András <pahia(a)t-online.hu>:
Hi,
I have just gave a shoot on Cuis 4.0 using SqueakVM 4.1.1 on Windows.
It even does not start, the crash dump is attached, but with the latest
Cog VM it runs fine.
I checked the older Cuis 3.3 image with the same SqueakVM, it runs fine.
Regards,
Andras Pahi
Cheers,
Juan Vuletich
On Sun, Apr 29, 2012 at 08:59:32PM +0200, Mariano Martinez Peck wrote:
> Hi David, can we ask you access to Guillermo Polito for the VMMaker repo?
>
> thanks!
>
(cc to vm-dev)
Certainly. Guillermo, please create an account on source.squeak.org,
and I will add you to the VMMaker project.
Dave
Commit notice too large for the list, forwarding trimmed version:
----- Forwarded message from vm-dev-owner(a)lists.squeakfoundation.org -----
Delivered-To: list-vm-dev(a)lists.squeakfoundation.org
Date: Sat, 28 Apr 2012 20:23:42.546 0000
From: commits(a)source.squeak.org
To: vm-dev(a)lists.squeakfoundation.org
Reply-To: vm-dev(a)lists.squeakfoundation.org
Subject: VM Maker: VMMaker-dtl.270.mcz
David T. Lewis uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker-dtl.270.mcz
==================== Summary ====================
Name: VMMaker-dtl.270
Author: dtl
Time: 28 April 2012, 4:23:12.307 pm
UUID: f17e6e57-c227-47a4-876c-287e33175b48
Ancestors: VMMaker-dtl.268
VMMaker 4.9
Add StackInterpreter and related classes, with additional changes to support ObjectMemory / Interpreter refactoring. The organization of the traditional Interpreter and ObjectMemory are now better aligned with the oscog branch of VMMaker, while the generated code for a standard VM remains equivalent to prior versions.
NewObjectMemory and StackInterpreter are not yet ready for use, and as always Cog and StackInterpreter VMs should be build from the oscog branch.
Upgrade note - If problems are experienced in generating a standard VM after loading this version of VMMaker, try recompiling the VMClass hierarchy, and reinitializing ObjectMemory and Interpreter. Pool variables are now used extensively, and in some cases a recompile may be needed to support the updates.
Changes that affect generated code:
- Allow inlining of ObjectMemory>>accessibleObjectAfter:
- All other changes are cosmetic, related to variable ordering, temp variable names, extraneous white space, etc.
- Generated code for the standard interpreter is equivalent to previous version, except that #accessibleObjectAfter: is now inlined.
Interpreter / ObjectMemory refactorings:
- Add StackInterpreter, StackInterpreterPrimitives, InterpreterStackPages, VMStructType and ReadOnlyArrayWrapper from oscog.
- Add CogClass and Cogit stub classes to support the refactoring.
- Add ObjectMemory subclass ClassicObjectMemory. Move methods that were overridden in NewObjectMemory from ObjectMemory to ClassicObjectMemory, and retain abstract implementations in ObjectMemory. Methods with 'self subclassResponsibility' are abstract and are not translated to C.
- The traditional object memory used with Interpreter is now ClassicObjectMemory, and the new object memory for StackInterpreter is NewObjectMemory, both of which are subclassed from ObjectMemory.
=============== Diff against VMMaker-dtl.268 ===============
<snip>
Hi Eliot. We are doing a crazy experiment where we serialize almost all
PharoCore and we materialize it in a PharoKernel image. During the
initialization (after the load), there is one line that crashes Cog:
PolymorphSystemSettings showDesktopLogo: true.
For what I can see, I may be related to the fact that #pharoLogoContents is
too long or something like that?
the same experiment with StackVM works fine.
Of course in a normal image (without this experiment) I can do
PolymorphSystemSettings showDesktopLogo: true. without problems.
>From gdb i see:
(gdb) bt
#0 0x0000a190 in compileCogMethod (selector=528828260) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/cogit.c:3601
#1 0x00009088 in cogselector (aMethodObj=531503072,
aSelectorOop=528828260) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/cogit.c:3129
#2 0x0003268b in ceSendsupertonumArgs (selector=528828260,
superNormalBar=0, rcvr=536158520, numArgs=0) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:11007
#3 0x1f40006c in ?? ()
#4 0x00067350 in threadSchedulingLoop (vmThread=0x1030c00) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:44006
#5 0x0003d2cb in initialEnterSmalltalkExecutive () at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:17788
#6 0x0003df8f in initStackPagesAndInterpret () at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:18208
#7 0x00022618 in interpret () at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../src/vm/gcc3x-cointerpmt.c:2066
#8 0x0006dc60 in -[sqSqueakMainApplication runSqueak] (self=0x1d0ca60,
_cmd=0x124ebf) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../platforms/iOS/vm/Common/Classes/sqSqueakMainApplication.m:174
#9 0x93ad586c in __NSFirePerformWithOrder ()
#10 0x908b8dd2 in __CFRunLoopDoObservers ()
#11 0x90874ced in __CFRunLoopRun ()
#12 0x908743c4 in CFRunLoopRunSpecific ()
#13 0x908741f1 in CFRunLoopRunInMode ()
#14 0x97760e04 in RunCurrentEventLoopInMode ()
#15 0x97760af5 in ReceiveNextEventCommon ()
#16 0x97760a3e in BlockUntilNextEventMatchingListInMode ()
#17 0x96d1a595 in _DPSNextEvent ()
#18 0x96d19dd6 in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#19 0x96cdc1f3 in -[NSApplication run] ()
#20 0x96cd4289 in NSApplicationMain ()
#21 0x0006b9f9 in main (argc=1, argv=0xbffff688, envp=0xbffff690) at
/Users/mariano/Pharo/VM/git/cogVMBlessedSSH/blessed/build/../platforms/iOS/vm/Common/main.m:52
And the line that fails is: allocateOpcodesbytecodes((numBytecodes +
extra) * 10, numBytecodes);
numBytecodes is 49729 and extra is 10.
Any idea?
thanks!
--
Mariano
http://marianopeck.wordpress.com