Squeak-dev April 2003

squeak-dev@lists.squeakfoundation.org

171 participants
517 discussions

[UPDATES] 4 new ones for 3.6alpha, using new process
by Doug Way 02 Apr '03

02 Apr '03

I just sent out emails approving 4 new updates for 3.6alpha. Well, 3 fixes and 1 test. These were incorporated using the process which has been hashed out here and on the SqF list. I will try to write up a swiki page summary tomorrow of the remaining bits of the process which are not already covered on other swiki pages. Since the other emails already announce the content of the updates, I may discontinue sending out this [UPDATES] email summary as well... we'll see. See http://swiki.gsug.org:8080/SQFIXES/ for the history of each submission. You'll see each one has an [update - 51xx] tag at the end. - Doug Way

1 0

Is there a Squeak3.x way to do "thisContext inquire"
by Brian Keefer 02 Apr '03

02 Apr '03

>From deep within the VI4 swiki page.. 'thisContext inquire message' will search the sender chain for the first receiver that understands message and send it to him. The receiver may choose to return a result or pass the inquiry by signaling the InquiryPass notification. If he returns a result, the result will be the result of the inquiry message. If he passes the inquiry, the search continues with his senders. If the search exhausts without finding a responsible receiver, an InquiryFail notification is raised, the default of which is to do nothing and return nil as the result of the inquiry message. Can this be done in Squeak 3?

2 2

[FIX] senderOfSplitName-asm ([sm][et][er] approved of by tpr)
by Tim Rowledge 02 Apr '03

02 Apr '03

I like this. Strongly approve for inclusion. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- They must have done a clean boot on him.

2 1

[BUG][TEST] Unwind blocks fail to evaluate when closing debugger
by Andreas Raab 02 Apr '03

02 Apr '03

Hi Guys, Here's a weird one - if you step within a debugger and then close the window, unwind blocks will not be evaluated correctly. The attached test illustrates both, the correct and the incorrect behavior. Any ideas?! Cheers, - Andreas

5 11

[FIX][Comanche] persistent connections
by Ian Piumarta 02 Apr '03

02 Apr '03

Comanche was not sending the correct 'Connection: {Keep-Alive,Close}' in the response header. The attached fix cures the problem allowing browsers that aggressively use persistent connections (e.g., Safari) to work without endless annoying "connection reset" errors. Ian

4 5

YASJITCI -- Yet Another Squek Just In Time Compiler Idea
by Andrew Berg 02 Apr '03

02 Apr '03

I'm writing this for two reasons: (1) To get some expert opinion on the feasibility of my idea, and (2) to distract this otherwise quite enjoyable list from its semiannual not-quite-flamewar-over-licensing. (That's a little joke, but it's probably only funny because it hurts so much.) Anyhow, this idea occurred to me about a month ago, and so far I have not figured out why it would not work, so I'm posting it up here for you all to shoot holes in so I can get back to my day job. Write the JIT compiler in Squeak itself. This is similar to what Bryce has been working on with Exupery, but I propose that simplicity is the order of the day. FORTH, where I spent a reasonable amount of my misspent youth, is pretty darn fast at runtime because all of the subroutine calls are lightweight, and the compiled "methods" are natively executable. I don't think we can make the method calls as lightweight as FORTH, nor do we really want to. But we can write compiled methods that are natively executable. The Exupery way is to write a real compiler, and there is my way (which I make no bones about: It will not perform as well) which is to have a table of bytecode implementations, which just get chained together between some somewhat generic prefix/postfix blocks, and then get the various jump addresses fixed up. For message sends, it seems obvious that we want to inline when the receiver's implementation is short enough, and we have a high enough confidince that it is the right one, to cache the receiver's implementation address when it is not, and to emit fallback-code for the rest. Proper register allocation is an important thing that I am almost completely throwing away. Years ago, when I wrote a FORTH compiler, it worked by emitting little chunks of code which were hand-written in assembly. My initial implementation assumed that at each chunk boundary there would be the top three stack elements in three specific registers, and that the pointer to the rest of the data stack lived in another register. What I quickly found was that it was often convenient to also be able to have one, two or four top values in registers, so I tried again with a slightly more complicated table where I kept track of how many stack elements were in registers and then provided multiple implementations of each basic word (think: bytecode) with various numbers of values in registers as preconditions, and with the most efficient number for the word as the postcondition. Along with a little table of nop instructions for filling holes in my hand-written table, it worked pretty good. My gut feeling is that this approach will give us XX% of what a full blown register allocation scheme will, for xx% the cost, where XX and xx are probably something around 85 and 15 respectively, just like everything else. What will it do for us performancewise? Well, on deeply pipelined superscalar cpu's, the worst thing you can do is to introduce a bubble in the pipe, and the easiest way to introduce a big bubble is to miss a branch prediction. Strictly speaking, a memory access that misses all the way out to the swapfile is probably bigger, but let's assume we can't do much about that case. Right now, we are probably suffering a branch mispredict on every bytecode, since the case statement implementing the bytecode interpreter is branching to all of the bytecodes from a single branch instruction. By naively chaining together sequences of machine code, without a doubt we will be generating more instructions than necessary, but with multiple instructions being dispatched per clock, the cost of these is quite low in comparison. What will it require for implementation? Well, as I see it, code in this implementation has three levels, and maybe more. Source code, compiled to bytecode and compiled to machine code are the obvious ones. In order to produce receiver class metrics for message send optimizing and inlining, it will probably be handy to add a fourth one, between bytecodes and machine code. Whether this layer should be bytecode or machine code, I don't really know. If message recipient's implementation addresses are to be placed directly into the machine code as jump addresses, then they need special handling from the VM to prevent movement during GC. I thought maybe if the jump addresses were stored in the constants table, then the VM would know to update them and everything would be fine. Yeah, there is an extra lookup for the jump indirect, but as long as branch prediction is usually correct it is probably OK. As I see it, the thing to do is to put a second layer of compiled to bytecode to gather receiver classes. Could we dedicate a seperate set of send bytecodes for this? Once the receivers are known, generate new bytecode which uses a new version of send something like 'sendMessage w to x ifItsClassMatches y returningTo z' and leaves a new return address which skips over the code for a regular, unknown send. Then this bytecode is what we use chunk-chaining to create executable machine code for. Ok, there's the idea. Anyone out there understand where I am trying to go with this? Anyone out there can tell me why it is a dumb idea? By the way, the last project I spent about 2 months worth of evenings working on was embedding Mozilla into Squeak. I gave up because: I realized that I really don't want to fiddle with Mozilla. It is a big, ugly, complicated beast, and it is written in C++. I use C++ at work because they pay me to. The last thing I want to do is to use it at home. :) -andrew -- andrew_c_berg(a)yahoo.com

2 2

[ENH] ContextCleanup ( more test-cases needed )
by Brent Vukmer 02 Apr '03

02 Apr '03

Here are the additional tests (code + docs) that seem to be needed: Context Control Enhancements --need SUnit test for ContextPart>>return --need SUnit test for ContextPart>>restart --need SUnit test for ContextPart>>jump --& etc. Process Control Enhancements --need SUnit test for Process>>completeStep: --& etc. Debugger Enhancements --need test plan that testers can walk through via the UI ContextTags --need SUnit test for MethodContext>>contextTag Exceptions Refactored --need SUnit test for Exception>>initialContext --need SUnit test for Exception>>handlerContext --need SUnit test for copying contexts safely --need SUnit test for searching for handler contexts Miscellaneous --need SUnit tests for "general additions to basic objects, collections, and streams" found in changeset #1 in ZIP See http://minnow.cc.gatech.edu/squeak/ClosureCompiler for details about this enhancement.

1 0

[FIX] MessageTallyBalloonFix-nk ( [sm][cd][et][sl] )
by Brent Vukmer 02 Apr '03

02 Apr '03

This fix is small, less than 1KB. The test case for the fix is well-documented. The preamble does not document the actual changes made for the fix -- however, only 2 lines of code in MessageSet class >> parse:toClassAndSelector: were touched: --changed "methodRef ifNil:" to "methodRef isNil ifTrue:" --added "methodRef isEmpty ifTrue: [^ csBlock value: nil value: nil]." I re-created the test case that Ned describes by executing the following DoIt and then clicking around in the resulting TimeProfileBrowser: TimeProfileBrowser onBlock: [20 timesRepeat: [Transcript show: 100 factorial printString]] No walkback appeared. I ran SLint on MessageSet; no problems were reported for the [FIX] changes.

1 0

[ENH] FileInGZDirectly-nk ( [sm][cd][sl][et] )
by Brent Vukmer 02 Apr '03

02 Apr '03

This enhancement is small -- around 5KB. The preamble accurately documents the changes the enhancement makes. I ran SLint on the classes affected by this enhancement: ChangeList, GZipReadStream and ReadStream. SLint didn't report any problems for this enhancement. I confirmed that after installing this changeset in a fresh 3.6alpha image, I could successfully browse, view decompressed, filein and/or install a gzipped-changeset. ( That's all the testing I did, though. )

1 0

Re: [ANN] Exupery, yet another compiler project
by Daniel Vainsencher 02 Apr '03

02 Apr '03

Bryce Kampjes <bryce(a)kampjes.demon.co.uk> wrote: > Daniel Vainsencher writes: > > Bryce Kampjes <bryce(a)kampjes.demon.co.uk> wrote: > > > Currently I only target x86 on Linux. It shouldn't be hard to extend > > > both to other operating systems and also to other CPUs. > > > > Perfect on both counts - that's what I use :-) > > <SNIP> > > I'll tell you one thing that sounds to me like it might be both useful > > and relatively easy to improve on - running the simulator. Since it's > > actually Slang (no dynamic sends), it's already a subset of the full > > Smalltalk problem (project 1.5?), and since it's currently either > > compiled externally (clumsy) or interpreted as full Smalltalk > > (relatively slow), you might make it more easily useful. > > > > If the simulator was fast enough to comfortably run regular size images, > > I guess people would use it more to learn about/debug problem images, > > and study the VM. Oh, we need to fix it in the image, too, but Craig's > > doing that... > > Interesting. I'm not sure if using an alpha compiler is going to help > people learn about the VM. If something works strangely what part of > the system do you blame? Well, at the beginning, it will mostly help you test your compiler. Then it will gradually move to helping other people. But that's as it should be :-) > The simulator is probably integer/symbol heavy so it should look > similar to my compiler. Besides that special handling of sends to self > would help more for the simulated VM than for normal code. I agree - it's definitely not the same problem as compiling full Smalltalk. Maybe it's not even a subproblem. But it's a somewhat useful problem that has much in common with it, and will test your compiler with a non-trivial piece of code. > > > I don't want to start trying to speed up sends until after > > > I've got useful byte code speed ups. > > Just curious - why? to partition it more clearly? > > I'm trying to carve out the smallest useful project. [snip] yes of course. But I assume you'll create a correct-but-unoptimized-at-all version first. At which point, is there any reason to prefer byte code speedups over sends? coming to think about it, one reason might be is that the most common things have been optimized by making them into bytecodes already, so bytecodes hold a lot of the execution time. Well, have fun :-) Daniel

1 0

Jump to page: