libera/#sicl - IRC Chatlog
Search
21:23:53
karlosz
lexical variables are not SSA, but besides that it's basically the same as any other SSA IR with lexical variables being represented as memory locations
21:25:32
karlosz
i can;t really think of any conceptual differences between BIR and the IR that's used in sbcl, except maybe that sbcl has an extra indirection for control flow that makes it easier to do conversion in a way that avoids redundant blocks
21:25:55
karlosz
also the meteevluation pass in sbcl actually implements fixpoint ineration correctly
5:39:21
moon-child
out of curiosity, does closos stand for anything in particular? 'common lisp object system operating system'? 'common lisp operating system (the operating system)'?
5:45:02
moon-child
my presumption was that it would have been 'common lisp operating system', but 'clos' was taken
5:46:32
mfiano
beach is a strong proponent of CLOS, and will yell it loudly if he gets the chance, and he did.
5:51:17
jcowan
SICL (and a fortiori CLOSOS) are CLOS_first: everything is a standard object except conses and immediates.
5:51:28
Bike
huh, the pdf doesn't actually mention what it stands for that i can see from a quick skim
5:55:25
jcowan
I'm not even sure that making conses not-standard objects is the Right Thing. Yes, it saves space, but it's not clear that conses really chew up so much space in toto. I don't know of any Scheme (except perhaps MIT Scheme) that uses a 2-word cell for conses.
6:11:43
hayley
If recompilation is acceptable, an indirection could be saved by only taking a Brooks read barrier while there are obsolete instances. Else it can be assumed that the read barrier is idempotent anyway. (Can instances be updated in the background? In another thread?)
6:12:49
beach
I think CONSes are used a lot for temporary things like lists, so there is a lot of allocation and garbage collection devoted to those. But this opinion is not based on any concrete evidence.
6:14:22
hayley
If the class CONS can never be redefined, then there is never a need for a forwarding pointer, as no code would ever try to follow a forwarding pointer. So a cons cell can be two words and like a standard object, by making other standard objects more like cons cells.
6:21:19
hayley
Like the omnipresent debugger, the barrier would be optimised (which I borrowed from Stopless, for anyone playing at home) by having versions of code with and without barriers. I'm also left to wonder if the barrier also suffices to implement concurrent compaction, too, since that's where the idea comes from.
6:22:21
moon-child
by the by: can we have 32-bit class + 32-bit hash, and then fix all the objects once somebody makes a hash table with >4g elements?
6:31:13
hayley
moon-child: Would it be possible to jump around read barrier code, and then patch jumps to not jump around read barrier code? Each thread would have to invalidate code caches, but threads needn't all be stopped at once. Might involve too much code bloat though.
6:42:04
hayley
Sure. And I don't have an idea for how to end up healing, so the read barrier couldn't be disabled either.
6:43:46
moon-child
I wonder about making the barrier a function you call, and can patch out. But idk if that's better than an inline branch
6:52:14
hayley
I've confused myself at the moment. Guessing that, without deoptimisation, there still needs to be some way to handle class redefinition anyway.
7:01:33
hayley
This would be much easier with deoptimisation, but we'd still have to deoptimise any code that uses standard objects. It would suffice to handle requests to deoptimise at safepoints; that's what Stopless does. Would type inference eliminate an interesting number of barriers here?
7:03:14
hayley
I'm not sure how to do self-healing either, with the barrier for standard objects being rather lazy. It's not easy to maintain that the mutator only ever sees up-to-date pointers, and we'd need a barrier before EQ too.