libera/#sicl - IRC Chatlog
Search
14:48:33
pjb
It's ironic. Stack for "activation records" were invented by LISP on machines that didn't have stack operations and dedicated registers. Then machines got them (SP, push, pop, call, return), and now everybody puts everything in this straightjacket. Now it's clear to me that nothing should be put on that hardware stack, but to let it be used by the processor only to manage interrupts (and perhaps call/return for efficiency), but
14:48:33
pjb
everything else, parameters, results, locals, clolsures should be allocated in activation records on the heap.
14:49:25
pjb
And if you have continuation you will want to copy the PC from the hardware stack to the activation records anyways, so…
16:16:44
pjb
beach: it's a problem only for the allocation: we need to have a part of the heap that can be allocated as a stack with minimal overhead, but that can later be garbage collected as usual (and with the frame possibly moved elsewhere if needed).
16:17:48
pjb
So instead of using a link instruction that reserves space on the processor SP, you'd do that on the heap frame stack pointer.
16:19:49
pjb
It could be less, even since on return you wouldn't need to unlink, you'd just let the garbage collector do its work.
18:31:13
pjb
beach: for short-lived processes, it's basically 0 (no GC needed). ;-) it's only a concern for long-lived processes, or processes using a lot of memory (ie. probably not short-lived)... Of course, this answer assume something like unix :-/
22:52:16
hayley
Cliff replied, saying "At this point, It All Depends. I tweaked the Java inlining heuristics in tandem with the register allocator, and a lot of dedicated profiling. In the end, a mix of callee and caller-save registers was best... BUT it was a lot more important that the allocator not spill excessively when over-inlining. i.e. the cost of the extra spills had to be close to the cost of the callee/caller saves you would have paid anyhow if you had