Squeak-dev July 2008

squeak-dev@lists.squeakfoundation.org

136 participants
183 discussions

Squeak by Example check for translation
by stephane ducasse 02 Jul '08

02 Jul '08

Hi all we would like to know the status of the current translations of the book. Of course we have to admit that the french squeakers are really cool :) Stef

1 0

[ANN] CorruptVM preview
by Igor Stasenko 02 Jul '08

02 Jul '08

Since lately there a some interest in C/C++ compiling and some people mentioned how it would be cool to make everything to be dynamically compiled, i decided to make a preview announce of a research which i done during last few months. A project name is a weird, and definitely it require more appropriate name to not scare off a potential users/developers, but this is not an issue right now :) Let me describe a little the key features of project and what goals it pursuing: - the main goal is to create a smalltalk language environment (similar to other smalltalks), but i avoid to call it VM, because its not really a VM, because there is no VM at all. - everything is written in smalltalk - system is completely self sustaining: smalltalk code compiled down to native code (no initial need in having bytecodes). Of course no-one prevents you from implementing a bytecode interpreter on top of it. But this is beyond the scope of current project. :) - there is no primitives nor need in writing external code in C (or in any other statically typed language). A primitives replaced by native methods (methods with <native> pragma), by using which you can implement any low-level behavior. - everything (by a 99.9% ;) in system is up to implementor. There is a few 'glue' semantics used by compiler, but compiler itself extensively using static inlining (inlining native methods from well-known classes such as CompiledMethod/ProtoObject or StackContext). Memory management/relocation, FFI , a diverse set of what we currently know as 'privitives' will be implemented in a system. This opens a potentially huge playground, how system would look like :) - avoid using global state. All state which code can potentially refer to is placed in literals. There is no difference between native methods and smalltalk methods in compiled method format. The difference only how they are compiled. Of course there will be some global state , i think it would be a single 'lobby' object, which contains a symbols table (required to support symbols uniqueness thoughout all system). But anyway, references to it will be possible only from method literals. - generated native code are location independent. Since all jumps will be relative, and all location-dependent stuff are either held in literals or computed. Therefore a CompiledMethod instances can be relocated freely in memory (by GC and friends) without any change that it will cause any harm. - compiler translates smalltalk code to a lambda representation. Then using different transformations it generates a low-level lambdas, which represent a virtual machine CPU instructions. No AST nor bunch of different classes to represent semantic elements of code used. Lambdas all the way down. - an object memory model is initially based on Ian's minimal object system. With some changes. You can download a snapshot of project at squeaksource: http://www.squeaksource.com/CorruptVM What is currently should work: CVMachineSimulator bootstrap -- bootstrap a object memory for simulation CVSimulationTests run -- run different tests on boostrapped object memory There are also an initial implementation of translating to native code using Exupery (you need to load Exupery for that). Do it: CVExuperyCompiler test inspect I am currently open for suggestions and advices or discussion in how is better to implement system based on such design. Would be glad to read your comments. There is also a wiki page of project: http://wiki.squeak.org/squeak/6041 -- Best regards, Igor Stasenko AKA sig.

4 10

Getting rid of Compact classes (Was: Re: [squeak-dev] The Primitive: I am not a number- I am a named prim! - SqueakPeople article)
by Igor Stasenko 01 Jul '08

01 Jul '08

2008/6/30 tim Rowledge <tim(a)rowledge.org>: > > On 30-Jun-08, at 12:15 PM, Igor Stasenko wrote: > >> 2008/6/30 tim Rowledge <tim(a)rowledge.org>: >>> >>> I am trying to make time to post a few articles on some future directions >>> I >>> consider interesting for the core system. >>> >>> First one is up at http://people.squeakfoundation.org/article/89.html - >>> do >>> please comment on the relevant page, or even here. >>> >> >> This is not the only things which i don't like. >> For instance look into ObjectMemory>>fetchClassOf: >> it fetching class depending on object header. Either from compact >> classes array (by index), or from slot, reserved for class reference. >> I think eliminating compact classes would simplify the access to >> object's class and free us some bits again: type mask bit (at least). >> >> It also will make fetching a class oop faster and uniform, so there >> will be no branching. >> Fetching a class from Compact classes array, requires: getting oop at >> index in special objects array, and then getting oop from this object: >> >> class := fetchPointer: ccIndex - 1 ofObject: (self fetchPointer: >> CompactClasses ofObject: specialObjectsOop) >> >> A drawback of getting rid of compact classes is additional memory cost >> per each instance of classes which were compact. > > Good points but perhaps for another thread? > > Here is an extended info, from ObjectMemory class comment: 3 bits reserved for gc (mark, root, unused) 12 bits object hash (for HashSets) 5 bits compact class index 4 bits object format 6 bits object size in 32-bit words 2 bits header type (0: 3-word, 1: 2-word, 2: forbidden, 3: 1-word) If a class is in the compact class table, then this is the only header information needed. If it is not, then it will have another header word at offset -4 bytes with its class in the high 30 bits, and the header type repeated in its low 2 bits. ----- So, as you would see, removing a compact classes will free 5 bits in common header , which then can be used by any object for what you mentioned: immutable flag, proxy flag etc. A tradeoff is increasing memory by 4 bytes (in 32bit images) for storing class oop in each instance of classes which were compact. Here the list of classes which is used as compact: Smalltalk compactClassesArray #(CompiledMethod MethodProperties Array PseudoContext LargePositiveInteger Float MethodDictionary Association Point Rectangle ByteString TranslatedMethod BlockContext MethodContext nil Bitmap nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil) And here the code which can tell us, how larger image would be after removing compact classes: | count | count := 0. Smalltalk compactClassesArray do: [:each | each ifNotNil: [ count := count + each allInstances size ] ]. count * 4 In my image its 2315548 extra bytes. The image size is 36368500 bytes. So, in percentage its roughly 6% space increase. I can't measure how faster (or slower) image would be if we remove compact classes, because it requires a conversion :) -- Best regards, Igor Stasenko AKA sig.

2 2

Jump to page: