Search
Sunday, 21st of January 2018, 0:29:30 UTC
3:43:12
beach
Good morning everyone!
3:43:30
beach
scymtym: Great, thanks.
3:45:24
beach
scymtym: Did you push your changes?
4:11:55
nyef``
More progress: I now have enough of a working TeX environment that I can build the SICL Specification document.
4:15:13
nyef``
On another front, I'm considering the possibility of a system in which all boxed values are pointers. That is, there ARE no immediate boxed values.
4:15:30
nyef``
In such a system, a FIXNUM becomes a "single-digit BIGNUM".
4:16:13
beach
That would certainly simplify the system, but also have an impact on performance, I would think.
4:16:28
nyef``
Yes, I would expect it to cons quite a bit more.
4:17:05
nyef``
The flipside is that I can add a software read-barrier fairly easily.
4:18:32
nyef``
I don't know if the overall result would be a win, but it's a section of the design space that might be interesting to explore.
4:19:00
beach
What were you thinking of using the read barrier for?
4:20:14
nyef``
Incremental computation of mark bits.
4:26:44
beach
So for parallel/concurrent GC?
4:31:03
nyef``
I'm probably not going to do anything with the idea *soon*, but the idea is there.
4:35:25
beach
Yes, things like that should preferably be documented somewhere.
4:37:24
beach
Speaking of GC, did I tell you about my latest thinking with respect to the memory management of SICL?
4:37:41
nyef``
I don't remember you doing so?
4:38:44
beach
Do you remember this paper, for the per-thread GC? http://metamodular.com/sliding-gc.pdf
4:39:14
nyef``
Yes, vaguely. I think that it may be on my re-read queue.
4:39:40
nyef``
And, yes, it's on my re-read queue.
4:39:49
beach
I am thinking of a single common GC with a mark-and-sweep for CONS cells and headers of general instances.
4:40:15
beach
And a malloc/free type heap for the "racks".
4:40:20
nyef``
mark/sweep, not mark/compact?
4:40:37
beach
Since all headers and all CONS cells are two words.
4:40:47
nyef``
Right, it's all two word structures, so a freelist is trivial.
4:41:13
nyef``
You might need to burn a tag on the freelist, but whatever.
4:41:19
beach
Plus, it means, no object in the older generation ever moves.
4:42:00
beach
So, if I allocate things like functions there, I don't have to worry about code moving around.
4:42:07
beach
Same thing for hash-table keys.
4:42:30
nyef``
You could even call out to C for malloc() for the racks?
4:43:23
beach
The [I forget his name] malloc/free library is quite good I hear.
4:44:43
beach
ACTION wishes his memory was not so crappy.
4:46:07
beach
And it can be simplified for Common Lisp. His allocator assumes that it is common that a malloc is followed by a free and vice versa. That is not going to be the case here. There will be lots of mallocs followed by lots of frees.
4:46:19
beach
So his cache can be eliminated.
4:47:37
beach
I think this can work, because the per-thread GC will catch a lot of transient objects, thereby cutting down on the load on the global GC.
4:49:43
beach
Anyway, just another point in the design space.
4:50:16
beach
But I have a feeling this is right for SICL, given the simple structure of heap-allocated objects.
11:55:28
scymtym
beach: hi. i didn't push yet. i wanted to ask how you would like to proceed. e.g. would you like to review changes first?
Sunday, 21st of January 2018, 12:29:30 UTC