Vm-dev October 2006

vm-dev@lists.squeakfoundation.org

31 participants
29 discussions

FW: [Vm-dev] RE: 64 bit Squeak
by barger 01 Nov '06

01 Nov '06

I already set up an ftp server with additional http access : http://www.barnet.sk/software/squeak/ ftp://ftp.barnet.sk login: squeak passwd: squeak Tomorow i will try to make some improvements, if you have any idea what should be done, let me know. >You can generate the 64 bit sources for this with any existing 32 bit >image and VM. If you run configure/make on a 32 bit machine, you get >a VM for 64 bit images that runs on 32 bit hardware. If you run >configure/make on a 64 bit machine, you get a VM for 64 bit imagse that >runs on a 64 bit host. I will try, but i believed that latest svn are for 64 bit image when not specified --with src=XXbits. Ian somewhere mentioned that he is now doing only one /src ... but maybe i am wrong. >Note that many plugins have not been updated for 64 bit VMs. Start with >the bare minimum (BalloonEnginePlugin, BitBltSimulation, FilePlugin, >and SocketPlugin) until you get a working VM. You can also safely >add OSProcessPlugin, XDisplayControlPlugin, and AioPlugin, but these >are not necessary to get a working VM. The only plugin that i realy need is SocketPlugin. >Give me an ftp account and password and I'll send you a working image >within 24 hours. You can see at the top, please let me know what you think and what the community will need in future, i want to help somehow on this 64bit slow evolution. I can also make any http interface from the seaside for this little repository, and i plan to make searchable interface to http links which are squeak related. Jan Barger

2 1

RE: 64 bit Squeak
by barger 31 Oct '06

31 Oct '06

Thanks for your quick answer... >I think that you are trying to run a 64 bit image with a 32 bit VM. I have both of this 64bit MIX. First i compiled on my AMD64 hw version with src=32bit and this VM can run images from /dev3 old link and also my current image, but i got the seg. fault on NetNameResolver because i thing there was no 64bit support for SocketPlugin. So i decided to compile as suggested full 64 VM ( with no src=xxbit option aj Ian mentioned on some web page in config script ) with the latest sources from svn from squeakvm. This produced incompatible version of image error and i am now no able to prepare new 64 bit image from 32, maybe it will take much more to study and investigate/ I run debian 64 bit OS on AMD64 and i can do quick switch to Intel CPU too because i sell hardware. >The 64 bit image requires a separate VM executable, which you need >to build by generating sources with the "64 bit VM?" check box selected >in VMMaker. This VM is required in order to run an image with 64 bit >Smalltalk word size. For do this i will need to solve all the chicken-egg problem. I first need to run on my 64bit Linux some system with at least net support ( 32 bit version fail on NetNameResolver and 64 bit on incopatible image ) >I run a 64 bit image occasionally, but only for the fun of seeing >it work. I also use it for updating various plugins that I maintain, >so they are 64 bit clean (OSPP, etc). Otherwise, I don't know of >anyone running 64 bit images right now. At least one person which is able to help somehow, thanks. >One other important thing that you need to know is that the original >64 bit image on the "dist3" site does not work with a current VM. I know because this was my first try. >I have attached a change set to show the method that has changed, >but it's a bit of a trick to actually do the update (I made a >custom hacked VM that tolerated either version of the image, and >used that to update the image to match the current VM). I will try to look at it too, but i think pure 64bit and proved-working image will be more helpfull at this time. >I think someone announced a web site for distributing useful images. >I guess I can upload a patched 64 bit image there if noone else is >has a better plan. I dont want to judge someone else plan to serve images, but i know that the best solution is always to do as much as i can by myself. So i can offer 10Mbit line with ftp and http access if you will be so kind and upload it there - to my machine. I can run it for years and i also run seaside web so maybe it can be interesting in future. Now there is only hardware e-shop at www.barnet.sk ,but i can build it all tomorow. Please let me know if you can upload your 64 bit image if i will do some web support for 64 bit squeak in future. >My understanding is that the system tracer only works on big-ender >machines (i.e. pre-Intel Macs). Maybe the problem is also in this big-endian, i dont look so deeply to image and vm sources. This was just my first try and one day testing. >There is now a "Squeak 64 bit" category on Mantis for tracking >64 bit Squeak issues. Currently there are three items that you >should read: I will check this too, thanks : >http://bugs.impara.de/view.php?id=5240 >http://bugs.impara.de/view.php?id=5239 >http://bugs.impara.de/view.php?id=5238 > >Dave Jan Barger

2 1

VM segmentation fault on NetNameResolver class>nameForAddress:timeout:
by barger 31 Oct '06

31 Oct '06

Hi, I compiled 64 bit vm from http://squeakvm.org/squeak64/dist3/ with src32 for testing with my actual image. Everything seems to work fine ( i run my websever with e-shop from this image with seaside ) , but NetNameResolver class>nameForAddress:timeout: End with Segmentation fault Is there any newer or devel. version of sources or just this mentioned : Squeak-3.8a-2.src.tar.gz 31-Mar-2005 16:11 3.1M I will also try to fix this by myself, but why not to ask first someone which solved it already ... Jan Barger www.barnet.sk <http://www.barnet.sk/>

2 4

Image Freezing
by Ron Teitelbaum 26 Oct '06

26 Oct '06

All, Ok after a little poking around I noticed: CTPusher >> startUp self shutDown. delay := Delay forSeconds: 15. process := SeasidePlatformSupport withName: 'ping' withLowestPriorityFork: [ [ self pingProcess ] repeat ] I've been working with Squeak for a long time now and never had the image freeze up on me before. The only thing I did differently was to load the Comet application. In the bug http://bugs.impara.de/view.php?id=4882 I noted that I was able to reproduce the error without starting seaside. The above code seemed like a good candidate, so I terminated the process. I was not able to get the image to freeze up after this. I tried changing the priority from 10 to 11 so that it would not run concurrently with idle process and it still had not frozen up on me. Does this process have to run at the same priority as idle? Is there a problem with a deadlock in the priority switching process of the vm? Ron Teitelbaum

2 2

Re: Efficient thread-local shared variables
by Klaus D. Witzel 24 Oct '06

24 Oct '06

Hi Nicolas, on Tue, 24 Oct 2006 09:39:31 +0200, you wrote: > Hi Klaus and Andreas > I find the local shared variable feature most useful. > I'am trying to understand your suggestions, ... > Klaus: > - have a single SharedPool with values being an array, and an index per > process? No, one Array per process and one integer index per shared variable. > pseudo code for PerProcessThing: > PerProcessThing localSharedValue > where localSharedValue is (^self at: Processor activeProcess > processIndex) No, Association subclass #LocalSharedVariable and then LocalSharedVariable>>localSharedValue <primitive: 4711> "this is what the primitive does faster:" ^ Processor activeProcess scope localSharedArray at: value LocalSharedVariable's key is the same as the key in the PerProcessThing association (for convenience), and LocalSharedVariable's value is the integer index into the localSharedArray. If you spend a primitive implementation and suppose that the example compiles to pushLiteralVariable: (#PerProcessThing -> aLocalSharedVariable) send: #localSharedValue "handled by primitive 4711" So exactly two bytecodes (without context switch) and, since you at least need to tell a "descriptor" and what you want from it (get or set a value), this identifies the least number of bytecodes necessary. > - have to reset all the shared value arrays each time a process is > created or die... This is independent of any proposal, you always have to allocate the shared value array per process, like in [[self allocateSharedValueArray. self doTheJob] ensure: [self destroySharedValueArray]] fork > I am not sure i understood well Klaus proposition > Did i get it ? I think so :) /Klaus > Nicolas > > Le Mardi 24 Octobre 2006 07:33, Klaus D. Witzel a écrit : >> Hi Andreas, >> >> on Tue, 24 Oct 2006 06:46:26 +0200, you wrote: >> > Folks - >> > >> > For a variety of reasons I am in dire need of the ability to vector >> > shared variables (globals, class vars and pool vars) through an extra >> > indirection vector per process (really per island but binding per >> > process seems to be simpler for now). Since I need this for *each and >> > every shared variable* it needs to be *very* efficient. >> > >> > The question is: What is the most efficient way to implement such a >> > scheme? >> >> The fastest indirect access is through literal variables (limited only >> by >> the # of literals allowed per method). >> >> Since you are willing to spend a #symbol per variable, formally declare >> a >> "descriptor" to be a class var (or use a pool). Take #PerProcessThing as >> as example; initialize PerProcessThing to a subinstance of Association >> which holds a fast and fixed Array index. >> >> Then all you need in the scope of activeProcess is a shared Array which >> is >> indexed by the above machinery. Example use: >> >> PerProcessThing localSharedValue >> PerProcessThing localSharedValue: somethingElse >> >> Not counting "Processor activeProcess scope", the above is the fastest >> double-indirect access that I can think of. >> >> /Klaus > > > > ________________________________________________________________________ > iFRANCE, exprimez-vous ! > http://web.ifrance.com

1 0

Efficient thread-local shared variables
by Andreas Raab 24 Oct '06

24 Oct '06

Folks - For a variety of reasons I am in dire need of the ability to vector shared variables (globals, class vars and pool vars) through an extra indirection vector per process (really per island but binding per process seems to be simpler for now). Since I need this for *each and every shared variable* it needs to be *very* efficient. The question is: What is the most efficient way to implement such a scheme? There are a couple of ways I can think about: 1) Just use a dictionary. The main disadvantage is the lookup cost which could be handled by making it a special kind of dictionary and implementing the lookup in a primitive. This is a good fallback position but probably just a little slow in general. It could implemented by something along the lines of: ProtoObject>>lookup: sharedBinding "Look up the value of the given shared binding in the currently executing process." ^Processor activeProcess scope at: sharedBinding ifAbsent:[nil]. which is pretty straightforward. 2) Use message lookup, e.g., send a message. This is simple to describe but not necessarily simple to implement correctly. Here is how the simulation would look like: ProtoObject>>lookup: sharedBinding "Look up the value of the given shared binding in the currently executing process." ^[Processor activeProcess scope perform: sharedBinding key] on: MessageNotUnderstood do:[:ex| ex return: nil]. One problem here is that the key needs to be unique within all possible keys which is a problem if there is a name conflict. This can be resolved by implicitly prefixing names with the place where they are defined so it's not such big of a deal conceptually but practically the impact of that change might be more visible. The other problem is that the scope object needs to hold all the objects which means quite a number of them. OTOH, one could argue that in many ways "Smalltalk" is just an object with a few thousand iVars so having a class representing the namespace defined by Smalltalk may be quite reasonable. 3) Use "some" integer index caching scheme. The main idea here is in realizing that really, option #2 doesn't quite work since classes can't have more than 256 iVars so we'd need to have an indirection through an array to be able to access these variables. If that is so, then why can't we inline the entire access pattern and have the scope just be an array that we index directly? This is actually the most interesting approach to me because (as far as I can tell) it would be by far the most efficient. The basic idea goes like this: If all shared variables are assigned a "global index" then only this index is required to use them. Any use of the shared variable Foo would be inlined to "Processor activeProcess scope at: FooIndex" which (given proper primitive support) would probably be by far the fastest version (if offered a byte code it should rival the current speed of accessing shared variables). [I'll admit that there are some tricky issues with this approach as well, like the size needed for the scope object and whether or not to use hash lookup instead of indexing] In any case, I'm trying to gather options. If any of you have any new ideas or have tried one or the other (successfully or not) or have any other comments to make I'd love to hear about it. Cheers, - Andreas

2 1

Fwd: Include Cryptographic Primitives In VM's - DESPlugin
by Adrian Lienhard 17 Oct '06

17 Oct '06

Begin forwarded message: > From: "Ron Teitelbaum" <Ron(a)USMedRec.com> > Date: October 16, 2006 9:24:00 PM GMT+02:00 > To: "'Adrian Lienhard'" <alienhard(a)netstyle.ch> > Subject: FW: Include Cryptographic Primitives In VM's - DESPlugin > Reply-To: <Ron(a)USMedRec.com> > > Adrian, > > Could you forward this for me to vm-dev, I tried but it was > rejected. I signed up again but didn’t get a response from mailman. > > > > All, > > When I originally sent this email I believed that DESPlugin was > part of VMMaker, I was wrong. I uploaded two files to mantis one > that is incorrect but I couldn’t delete it, and a correct version > which should be considered the notes should make it clear. > > Please let me know if you need anything else, or have any > questions. Thanks for your help! > > Ron Teitelbaum > > > > From: Ron Teitelbaum [mailto:Ron@USMedRec.com] > Sent: Thursday, October 12, 2006 9:52 AM > To: 'vm-dev(a)discuss.squeakfoundation.org'; 'Cryptography Team > Development List' > Subject: Include Cryptographic Primitives In VM's - DESPlugin > > http://bugs.impara.de/view.php?id=5228 : > > Hans-Martin did some testing and as we expected the performance of > pure squeak cryptography is disappointing: > > Hans-Martin wrote: > > "Ok, I did some measurements. Results are pretty disappointing. > > Squeak on my AMD 3800+ processor encrypts 32 KBytes using 3DES CBC > mode in about 8 seconds - unusable for anything but a proof-of- > concept. > > Therefore I think that DES (and maybe some other small cryptographic > > primitives) should be part of the base VM." > > > > The DESPlugin is already a part of the VMMaker, I am asking the VM > group to please include the DESPlugin in the base VM that is > distrubuted. We will be submitting more code and will follow the > process of code -> VMMaker -> VM. If the VM team wants to wait > before building a new VM's until other primitives are available, > that is fine, but if a build is going to be done anyway for other > issues, please include the DESPlugin. > > > > Thank you for your help! > > Ron Teitelbaum > > Cryptography Team Leader > >

7 15

$B>!<j$K$4$a$s$J$5$$!"(B
by まや 13 Oct '06

13 Oct '06

貴方のアドレス、アドレスを売っている業者から買いました。どうしても男性と体の関係になりたくて、まだ経験した事無いんです、こちらでhttp://sruq… 私の写真確認して、もしOKでしたら、私のアドレスにメールください。マヤっていいます。メール受信拒否 I don't veceive yourmail star_dast1000(a)yahoo.fr

1 0

$B4IM}?M<+?H$r;}$C$F$*%9%9%a$7$^$9!*(B
by 橋本　潤子 13 Oct '06

13 Oct '06

H$B$J$*;P$5$s$,?tB?$/B8:_$9$k!*(B $BMxMQ<T$NG/NpAX$O#2#0BeA0H>!A#3#0BeA0H>$,B?$/!"$7$+$b=w$N;R$N%l%Y%k$,Hs>o$K9b$$!*(B $B<B:]$K%"%]$,$H$l$F$$$6LL@\$H$J$k$H!"$=$N#83d$O2a?)%l%Y%k!*(B $B<A$r5a$a$k$J$i$3$N%5%$%H$7$+$J$$!*!*(B $B=w@-$N3hF0N($b9b$/!"<B:]$NMxMQ46$G$O!"CK@-#4#0!s!'=w@-#6#0!s$/$i$$$K46$8$i$l$k!#(B $BHs>o$KJV?.N($,9b$$%5%$%H$@!#Nx?MJg=8$+$i%;%U%l$d!"3d$j@Z$j%o%s%J%$%H=P2q$$Ey!"(B $B=w@-$N=P2q$$Jg=8$NL\E*$O@i:9K|JL!#(B $B5.J}$NL\E*$K$"$C$?=P2q$$$r8!:w$9$l$P#o#k!#(B $BFC$K!"!X7Z$$$*IU$-9g$$!Y$,B?$/!"(B $B2q$C$F$9$0$K%[%F!<%kD>9T$NB(%2%C%H$,%d%j0W$$%5%$%H!#$A$g$C$T$j%(%C%A$JCK@-$K$O%*%9%9%a$J%5%$%H!#(B http://sruq.com/?c119 $B<u?.5qH](B star_dast1000(a)yahoo.fr

1 0

vm-dev$BMM$K$*FO$1J*$N$40FFb$G$9(B
by 松下めぐみ 13 Oct '06

13 Oct '06

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2006