libera/#sicl - IRC Chatlog
Search
6:18:42
hayley
Well, I sent an email to Cliff Click asking about what he thought about callee saved registers, and I expected to not get a response any time soon. I was amazingly proved wrong.
6:23:27
hayley
The context was the "Bits of advice for VM writers" presentation, where he is also critical of callee-saves registers on x86 <https://www.youtube.com/watch?v=vzzABBxo44g>. I asked if he thought inlining (or call site optimization) changes the assumptions made, and if he thinks callee-saves is a good idea on x86-64 or ARM.
6:24:49
hayley
He said callee-saves was very messy in concurrent stack scanning on HotSpot, and "it wasn't really worth it for all the very-low-frequency GC bugs that entailed." And that callee-saves can sometimes get a small win on x86-64, because spilling is optimized. But on a RISC there is a larger win.
6:25:36
hayley
But, as he said it was "since leaf routines make up (nearly by definition) 50% of all calls", I wonder if I didn't communicate that I was interested in how these change under inlining.
6:36:00
hayley
I have sent a reply asking if he would change his mind with inlining, as our (some of the SICL developers) hypothesis is that there would be fewer but larger leaf functions under inlining or call site optimization.
7:30:56
moon-child
I wonder if https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html would be useful for implementing barriers
7:31:31
moon-child
though I'm not sure the extent to which it's available on production hardware; it has apparently been ported to riscv
7:56:04
beach
I wonder where all these people get all these resources. It looks like a huge amount of work.
7:57:10
moon-child
it would be an understatement to say that java was _very_ commercially successful
8:01:14
beach
With respect to callee-saves registers, I am not convinced that they are not worth the trouble for a dynamically typed language with automatic memory management.
8:03:53
shka
https://www.eetimes.com/arm-to-deliver-cheri-based-prototype-to-tackle-security-threats/#
8:04:28
shka
military and intelligence community in the USA is very concerned about the security of the computer systems
8:08:33
beach
It is "amusing" to me that all these resources are spent on trying to make intrinsically unsafe language somewhat safe, rather than on using good languages instead.
8:17:06
shka
and getting even few percent of saved memory/cpu time on the scale of azure would lead to millions of dollars in savings
8:17:50
shka
plus there are those intel security bugs, if you could somehow run old microcode version safely, again a lot of money saved
8:30:58
hayley
I think beach's claim that callee-saves registers are not worth the trouble for a dynamically typed language with automatic memory management could be generalised to any language with automatic memory management and an implementation which does some inlining, though we have only done the thought experiment for Common Lisp and have experimental evidence for Java.
9:46:09
hayley
It reminds me of when someone decided having fixnums and bignums was only possible with dynamic typing. Must suck to be a Haskell programmer. So I guess it would also apply to Haskell given there is some inlining there too.
9:47:18
hayley
(At least I think GHC has the most work put into it for ML-family language implementations. Just a guess though.)
9:50:46
beach
I did not know about any lazy ML, so I thought that was what distinguished them. Thanks.
9:54:05
hayley
Without thinking about it too hard, I decided that Java, Haskell and Common Lisp would represent any other language with automatic memory management well enough.
9:55:21
hayley
Now I think I should also have put Prolog and Erlang in that set, for logic programming and actors respectively. But I am not as familiar with any implementation of the former.
9:57:00
moon-child
notably apl, objc, and there's a research language from ms that tries to statically minimize rc changes
9:58:29
hayley
Well, what does memory management affect in this case? From memory the original prediction made was only based on the presence of inlining.
9:59:25
beach
Automatic memory management requires stack scanning and that becomes much more difficult in the presence of callee-saves registers.
10:00:15
hayley
Aha, right. From memory, only deferred reference counting requires stack scanning, and that is quite uncommon compared to, I suppose immediate reference counting.
10:00:19
beach
An object belonging to a particular function deep in the stack can be in a register close to the top of the stack.
10:01:13
hayley
moon-child: The last one is Koka, right? It is strange to me because I use functional data structures to make use of structure sharing and concurrency, which is quite the opposite of what it optimizes for.
10:02:48
moon-child
I believe so, yeah. I haven't looked at it super closely, just remember skimming the abstract to a paper about it
10:03:05
hayley
All I remember is that Smalltalk implementations tended to use deferred RC before Ungar's generational scavenger, and RCImmix uses it for a minor performance improvement and a vague, untested promise of "incremental collection".
10:13:01
hayley
So on paper, implementations using reference counting could be affected, but in practice, it is unlikely.
11:28:22
edgar-rft
reference counting is important in Scheme since there are so many references, currently it's R7RS but someday RnRs might run out of the fixnum range
11:30:59
hayley
Well, reference counting was preferred for so long in Smalltalk because activation records (i.e. the call stack) are first class objects, and die quickly. So tracing mostly just cleared out activation records.
11:32:00
hayley
I am fairly sure one can implement continuations with first-class activation records, but I forget how. At least process scheduling in Smalltalk-80 was done by swapping contexts when a timer interrupted the system.
11:32:52
hayley
Come to think of it, the current activation record is a continuation, given you stuff enough context into the record.
11:58:17
hayley
Right, it just took a while to remember that everything is stored in the activation record. Though I should check with the Blue Book...
12:13:44
beach
Interestingly, before I learned Scheme, I always thought of the stack as representing the history of the computation so far, but Scheme taught me that it represents the future of the computation, i.e., the continuation.
14:07:43
sm2n
also, apple's (relatively) new m1 arm hardware has an extension for pointer integrity tagging