change layout to type

salama/memory.md

@@ -1,9 +1,9 @@
 ---
 layout: salama
-title: Memory layout and management
+title: Types, memory layout and management
 ---
 
-Memory management must be one of the main horrors of computing. That's why garbage collected languages like ruby are so great. Even simple malloc implementations tend to be quite complicated. Unneccessay so, if one used object oriented principles of data hiding.
+Memory management must be one of the main horrors of computing. That's why garbage collected languages like ruby are so great. Even simple malloc implementations tend to be quite complicated. Unnecessary so, if one used object oriented principles of data hiding.
 
 ### Object and values
 
@@ -19,29 +19,30 @@ If integers were normal objects, the first would mean they would be singletons.
 
 Instead of trying to make this difference go away (like MRI) I think it should be explicit and indeed be expanded to all Objects that have these properties. Words for examples (ruby calls them Symbols), are the same. A Table is a Table, and Toble is not. Floats (all numbers) and Times are the same.
 
-### Object Layout
+### Object Type
 
-So if we're not tagging we must pass and keep the type information around seperately. For passing it has been mentioned that a seperate register is used.
+So if we're not tagging we must pass and keep the type information around separately. For passing it has been mentioned that a separate register is used.
 
-For keeping track of the type data we need to make a descision of how many we support. The register for passing gives the upper limit of 4 bits, and this fits well with the idea of cache lines. So if we use cahce lines, for every 8 words, we take one for the type.
+For keeping track of the type data we need to make a decision of how many we support. The register for passing gives the upper limit of 4 bits, and this fits well with the idea of cache lines. So if we use cache lines, for every 8 words, we take one for the type.
 
-Traditionally the class of the object is stored in the object. But this forces the dynamic lookup that is a good part of the performance problem. Instead we store the Object's Layout. The Layout then stores the Class, but it is the layout that describes the memory layout of the object (and all objects with the same layout).
+Traditionally the class of the object is stored in the object. But this forces the dynamic lookup that is a good part of the performance problem. Instead we store the Object's Type. The Type then stores the Class, but it is the type that describes the memory layout of the object (and all objects with the same type).
 
-This is is in essence a level of indirection that gives us the space to have several Layouts for one class, and so we can eveolve the class without having to hange the Layout (we just create new ones for every change)
+This is is in essence a level of indirection that gives us the space to have several Types for one class, and so we can evolve the class without having to change the Type (we just create new ones for every change)
 
-The memory layout of **every** object is type word, layout reference and "data".
+The memory layout of **every** object is type word followed by "data".
 
 That leaves the length open and we can use the 8th 4bits to store it. That gives a maximum of 16 Lines.
 
 #### Continuations
 
-But (i hear), ruby is dynamic, we must be able to add variables and methods to an object at any time. So the layout can't
-be fixed. Ok, we can change the Layout every time, but when any empty slots have been used up, what then.
+But (i hear), ruby is dynamic, we must be able to add variables and methods to an object at any time.
+So the type can't be fixed. Ok, we can change the Type every time, but when any empty slots have
+been used up, what then.
 
-Then we use Continuations, so instead of adding a new variable to the end of the object, we use a new object and store it
-in the original object. Thus extending the object.
+Then we use Continuations, so instead of adding a new variable to the end of the object, we use a
+new object and store it in the original object. Thus extending the object.
 
-Continuations are pretty normal objects and it is just up to the layout to manage the redirection.
+Continuations are pretty normal objects and it is just up to the object to manage the redirection.
 Off course this may splatter objects a little, but in running application this does not really happen much. Most instance variables are added quite soon after startup, just as functions are usually parsed in the beginning.
 
 The good side of continuation is also that we can be quite tight on initial allocation, and even minimal with continuations. Continuations can be completely changed out after all.

salama/optimisations.md

@@ -17,10 +17,10 @@ But this can easily lead to a dictionary/hash type of implementation. As variabl
 common thing an OO system does, that leads to bad performance (unneccessarily). 
 
 So instead we keep variables layed out c++ style, continous, array style, at the address of the object. Then we have 
-to manage that in a dynamic manner. This (as i mentioned [here](memory.html)) is done by the indirection of the Layout. A Layout is 
+to manage that in a dynamic manner. This (as i mentioned [here](memory.html)) is done by the indirection of the Type. A Type is 
 a dynamic structure mapping names to indexes (actually implemented as an array too, but the api is hash-like).
 
-When a new variable is added, we create a *new* Layout and change the Layout of the object. We can do this as the Layout will
+When a new variable is added, we create a *new* Type and change the Type of the object. We can do this as the Type will
 determine the Class of the object, which stays the same. The memory page mentions how this works with constant sized objects.
 
 So, Problem one fixed: instance variable access at O(1)
@@ -44,11 +44,11 @@ The Plock can store those cache hits inside the code. So then we "just" need to
 
 Initializing the cached values is by normal lazy initialization. Ie we check for nil and if so we do the dynamic lookup, and store the result. 
 
-Remember, we cache Layout against function address. Since Layouts never change, we're done. We could (as hinted above) 
+Remember, we cache Type against function address. Since Types never change, we're done. We could (as hinted above) 
 do things with counters or robins, but that is for later.
 
-Alas: While Layouts are constant, darn the ruby, method implementations can actually change! And while it is tempting to 
-just create a new Layout for that too, that would mean going through existing objects and changing the Layout, nischt gut.
+Alas: While Types are constant, darn the ruby, method implementations can actually change! And while it is tempting to 
+just create a new Type for that too, that would mean going through existing objects and changing the Type, nischt gut.
 So we need change notifications, so when we cache, we must register a change listener and update the generated function,
 or at least nullify it.