freenode/#sicl - IRC Chatlog
Search
4:26:31
jcowan
can someone explain to me how the gc decides whether slots in the rack are pointers (including immediates) or binary data?
7:31:00
beach
jcowan: In SICL all objects have a tag, so the tag determines the type. There are no "raw" objects in the rack, at least not at the moment.
7:31:41
beach
jcowan: But I could allow that. The rack also contains a list of the slot metaobjects as they were in the class when the instance was created.
8:03:34
jcowan
beach: I'm curious about things like bit, byte, and float vectors, which surely don't box their elements.
8:04:30
beach
jcowan: Correct. The type of the object itself would determine whether the elements are boxed.
8:05:18
beach
In SICL a bit vector would have a class object that indicates that the elements are not boxed.
8:07:14
jcowan
But the class of an array can't specify its total size, can it? (I can see treating arrays with different ranks as different classes.)
8:08:08
jcowan
But how do you know that the rack of one simple-vector holds 5 slots and another 5000 slots/
8:10:00
jcowan
Ah, okay. So tha length of a rack depends not only on its associated class but also in the content of the rack.
8:13:40
jcowan
In Smalltalk the layout of objects (other than fixnums) is a length word, a class word, and the slots. A bit stolen from the length word tells whether the slots are pointers or raw.
8:26:00
beach
Speaking about uniform, in SICL every heap allocated object is either a two-word CONS cell, or a two word HEADER with a pointer to the class and a pointer to the rack. That is a very uniform representation, and, as it turns out, I was able to design an interesting memory management system thanks to this uniformity.
9:15:35
heisig
Especially to compare how long it takes to allocate on the stack vs. how long it takes to allocate on the heap. Will there even be a difference?
9:16:57
no-defun-allowed
most of the time nurseries are done as copying gcs, which most of the time just bump a pointer
9:17:13
no-defun-allowed
well, all copying gcs bump pointers to allocate, my bad, but i'll check sicl.pdf for the spec
9:17:20
heisig
The other thing is how expensive it is to have write barriers to the global heap. Not sure how that plays out.
9:18:17
no-defun-allowed
okay, the sicl nursery will use a "sliding" collector but it also seems to be a pointer bumping scheme
9:20:34
heisig
I know. If I understand correctly, the pointer bumping does not even need to be atomic. So the total overhead of consing is just a (correctly predicted) branch.
9:22:03
beach
Also, promotion is more precise that in most copying collectors, and the effect of that feature is hard to measure or even predict.
9:24:21
beach
In most copying collectors, promotion is a result of surviving a nursery collection, but then there is a certain probability that newly allocated objects will be promoted, even though it is very likely that they will die young.
9:25:27
Shinmera
beach: I don't see how you can do an array size increase with just a CAS. What about the case where one thread is in the process of copying the array to increase its size, but then another comes in and sets an element in the old array?
9:26:07
beach
Shinmera: I can't correct incorrect programming. All I can do is to make it thread sae.
9:27:33
Shinmera
There are techniques for lock-free adjustable vectors. Part of that is needed for a lock-free hash table that I was working on implementing at one point (before I got distracted)