Saagar Jha

Hot take: program stacks should be (more or less) infinite
6 replies →
6 replies

Andy Wingo

(replying to Saagar Jha)

@saagar preach!


Daniel Kochmański

(replying to Saagar Jha)

@saagar more infinite! not less! ;)

Saagar Jha

(replying to Daniel Kochmański)
@jackdaniel I wish but the current RAM prices may make this difficult

Daniel Kochmański

(replying to Saagar Jha)

@saagar that's why we should go only forward with the stack, then the beginning can be garbage collected (and no, I don't like scheme _that_ much)


Michel Schinz

(replying to Saagar Jha)

@saagar Hotter take: there should be no stack, activation frames should be allocated from the heap like everything else.

Saagar Jha

(replying to Michel Schinz)
@michelschinz Yes and that heap is a bump arena


shac ron ₪‎

(replying to Saagar Jha)

@saagar Embedded systems say no

Saagar Jha

(replying to shac ron ₪‎)
@shac Embedded systems also say no to heaps often

Phairupegiont

(replying to Saagar Jha)

@saagar Hotter counter-take: recursion is control flow obfuscation, it gives up the benefits of structured programming.

Ocaml was right to require explicit marking of recursive functions, so that we can know most of the code is free of this danger

Saagar Jha

(replying to Saagar Jha)
I’m sick of ruining perfectly good recursive code because “iT mIgHt StAcK oVeRfLoW”. Dude I have endless virtual address space. If I put all this on the heap it would work just fine. Figure it out
3 replies →
3 replies

Félix

(replying to Saagar Jha)

@saagar enjoy accidental infinite recursion eating all of your RAM

2 replies →
2 replies

methoxyf

(replying to Félix)

@fay59 @saagar is this a post about firefox


Saagar Jha

(replying to Félix)
@fay59 If you’ve got a bug in your loop the memory’s got to come from somewhere be it recursive or not

Félix

(replying to Saagar Jha)

@saagar also enjoy the debugger taking 15 minutes to give you a backtrace when you stop your process by hand

2 replies →
2 replies

Saagar Jha

(replying to Félix)
@fay59 This sounds like something a debugger should know how to solve

Andy Wingo

(replying to Saagar Jha)

@saagar @fay59 there are solutions to all of these problems wingolog.org/archives/2014/03/


Jason Molenda

(replying to Félix)

@fay59 @saagar fake news, lldb has an optimized stack walker specifically to handle inf recursion crashes well; I think the most stack frames you can get with std main thread stack size is ~500k frames; lldb can walk that in 5.5 seconds on my m4 max desktop. I mean unlimited stack means really infinite recursion crash ofc, 500k is just the start of what you could do in that env.

Jason Molenda

(replying to Jason Molenda)

@fay59 @saagar (if you have lldb formatting argument variables for each stack frame, that’s gonna take longer of course - lots of memory reads and type formatters. but just looking at “lldb has enumerated all stack frames, and knows the pc values with symbol name and debug info for each”, 5-6 seconds max.)

Félix

(replying to Jason Molenda)

@jasonmolenda @saagar I don’t stack overflow all that much but I recall at least Xcode not being very good at it. maybe I’m unjustly blaming lldb for it

Jason Molenda

(replying to Félix)

@fay59 @saagar to be fair, in the early days I’d written lldb’s register tracking up & down the stack with a recursive algorithm and you can guess what happened next.


Marin Todorov

(replying to Saagar Jha)

@saagar but what about all these people who have this question on their coding interview list, imagine the amt of manhours to replace it with new one... think about the economy and productivity 😱


Jesse Wilson

(replying to Saagar Jha)

@saagar or abuse your favorite language’s async feature

Kotlin:

suspend fun sum(a: UInt, b: UInt): UInt {
enableDeepRecursion()
if (a == 0) return b
return sum(a - 1, b + 1)
}

suspend fun enableDeepRecursion() {
yield() // ✨
}

Saagar Jha

(replying to Jesse Wilson)
@jessewilson Yeah it’s funny that you can basically just make languages do this inefficiently if you want but you can’t get them to do it efficiently